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In this Issue 

Process improvement, cost savings, shorter time to market, quality and produc- 
tivity, and customer satisfaction are some of the goals that dominate the mission 
statements of many manufacturing organizations. The two sets of articles in this 
issue are from two different areas associated with computer systems manufac- 
turing. The first six articles cover the processes involved in developing software 
systems, with five of these articles from HP's Corporate Engineering software 
initiative program. This program is an effort to make software development a 
core competence at HP The second set of articles, covering the manufacture of 
printed circuit boards, consists of papers presented at HP's 1995 Electronic 
Packaging and Manufacturing conference. 

The first article (page 6) is a good example of a process improvement effort. The article describes a 
successful project at HP's Software Engineering Systems Division to put in place a software development 
process model called the Capability Maturity Modet (CMM). CMM was developed by the Software Engi- 
neering Institute at Carnegie-Melion University. This model has five stages, or maturity levels. Each 
succeeding level dictates ever stricter quality processes to be in place for evaluating software products. 
Because of the strict requirements of CMM, it normally takes an organization 36 months to go from 
level-! to level-2 CMM compfiance. The authors describe how their organization was able to reach 100% 
level-2 CMM compliance in less than a year. 

We ail know that if we don't learn from our mistakes, we are bound to repeat them. This is the central 
theme for the article on page 15 in which the author encourages software developers to perform a failure 
analysis on their software defects (mistakes! to understand the root cause of each defect. With the les- 
sons learned from this analysts an organization can do the appropriate things m its development process 
to prevent certain defects from occurring again. The article also describes a way to classify software 
defect data, and the steps an organization can take to collect, analyze, and use defect data to make 
improvements its software development process. 

The traditional waterfall life cycle has served software developers well for many years. With this model, 
once customer and system requirements were captured in the requirements phase, developers could 
proceed through each phase until manufacturing release without revisiting any of the previous phases 
or collecting any more customer input. This model worked well when competition was limited and soft- 
ware had life spans of several years. Today, competitive products, customer needs, and even develop- 
ment tools change every few months. An alternative [ife cycle is described in the article on page 25. This 
new model, called Evolutionary Fusion, breaks the software life cycle into smaller chunks so that certain 
phases are revisited and customer input is allowed throughout the development process. Fusion is a 
systematic software development method for object-oriented software development This article is a 
first for the Journal in that it is an excerpt from a chapter in an HP Press book entitled Objsct-OrienlBd 
Development at Work: fusion in the Real World, published by Prentice-Hall PTR in 1996. 

Discussion about the evolutionary model for software development continues in the next article on page 
39. In this article the authors present practical examples of the model's application to projects within HR 
It also discusses factors that affect the success or failure of using evolutionary development. 

It is pretty well accepted, that if a software design team can reuse an existing component during product 
development, they will reap great benefits in terms of productivity, quality, time to market, and cost savings. 
The queshon is, what is a component? In early software reuse efforts, software components consisted of 
libraries of general-purpose routines or functions. However, recent software reuse efforts have focused 
on items such as designs, architectures, applications, and of course, code, as viable software components. 
As the article on page 46 points out, architecture-based, domain-specific reuse can yield greater quality 
and productivity improvements than earlier reuse efforts. A domain-based reuse strategy focuses on 
finding a set of systems or applications that share some common functionality. The article describes a 
domain-based technique called HP domain analysis. 
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The next article on page 56 continues the software reuse discussion by talking about building software 
products on top of an established software platform. The autfior describes a platform development 
model that includes not only considerations regarding acceptable cnteria for a software platform to be 
reusable, but also the management and environmental issues associated with platform development and 
software reuse. The article has a very good discussion about the interactions between platfonn and 
product development life cycfes. 

Software and hardware designers have at least one thing in common today, and that is choosing the 
best components to use in a product from among the many choices available. The article on page 72 
describes a decision support tool called PASS (Package Selection SystemL which enables integrated 
circuit designers to choose the best package for an integrated circuit from the large number of packaging 
alternatives available, many of which have similar capabiiities. PASS is an in-house expert system that 
uses data from various packaging contractors to come up with a listof technically feasible afternatives 
based on the criteria input by the designer. 

Once the integrated circuits are in their packages, they must be mounted on the printed circuit boards. 
The productivity goal in this process is to keep the component placement time (cycle time) for each 
board as short as possible. This is particularfy important in a high-volume shop because most of the 
assembly time is spent in part placement. The article on page 80 describes how one HP surface mount 
center using Fuji IP2 pick-and-place machines was able to improve its cycle time by 16% over hand- 
created and optimized pick-and-place recipes. The techniques they used to achieve this improvement 
have been incorporated in setup and sequence generation modules for HP's Man-Link recipe generation 
system. Other enhancements to the Man-Link tool reduce the time to set up pick-and-place machines by 
ordering the boards being assembled to exploit the commonality of parts among them and by creating 
sequences of setups that differ very little from one another (page 84). 

After selecting the best package for the integrated circuits and efficiently placing them on the printed 
circuit boards, the next step is to anchor them to the boards with solder and flux. The goal here is to 
anchor components to the board with solder and flux materials that reduce the risk of thermal shock and 
allow multiple reflows on a single board. The articles on pages 91 and 99 describe efforts to develop a 
low-temperature solder and flux that woufd make thermal-shock reduction end multiple reflows feasible. 
The article on low-temperature solder describes the examination of afloysthat melt at temperatures 
between 50 G and 183 C. Fmding an alloy with a low-temperature melting point is only the first step in 
developing a low-temperature soldering process. A suitable ftux must be found that activates at temper- 
atures 20 to 30" C below the melting point of the solder alloy and bonds the solder to the electrical con- 
ductor. The second article describes the investigation into this alloy-flux interaction, 

C.L Leath 
Managing Editor 



Cover 

A computer-colorized and embossed photograph of a cracked 58Bi42Sn solder joint, showing that the 
brittle fracture of the Bi-rich phase (lightly colored phased was the cause of the brittle failure of the 
solder [see article, page 91). 



What's Ahead 

In the October issue well have nine articles on telecommunication network management The articles 
will focus on the tools offered by HP for developing telecommunication network management applications. 
Other articles include an overview of HP's storage management solutions, a description of HP's first gigabit 
Fibre Channel controller for connecting host systems to high-performance networks and mass-storage 
peripherals, and an introduction to the Fibre Channel standard. 
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Implementing the Capability Maturity 
Model for Software Development 

Continuous support for a software development innprovement effort 
requires at least two things: a ciearly defined improvement model and 
success at applying the model in the organization. One HP division was 
able to apply one such model and achieve measurable success on several 
product releases. 

by Douglas E, Lowe and Guy M, Cox 



Manufacturing enlities are always looking for more efficient 
ways of producing products because tliey realize that an effi- 
cient process yields low^r costs, better quality, and increELsed 
customer satisfac'tion. Softw^are manufacturers aie no differ- 
ent from theii' ^laidw^are count en j^arts in that they wtmt to 
use the best softwaie development process available. The 
Capabitity Maturity Model (CMM) for software, developed at 
the Softw^are Eingineeiing Institute (SEl) at ('arriegie-Mellon 
University/' is a process model thai provides excellent guid- 
ance to improve software development processes. 

The Model 

CMM is used to evaluate and improve the way softw^ui e is 
built and maintained. Fiist released in 1987, CMM was origi- 
naUy based on tlie experience of members of SEl. CMM has 
been contiimously improved and refined since 1987 tli rough 
successive revisions based on industiy^ide and worklw itle 
input. Yet, even though it is based on experience, it is only a 
model, which is iui abstract , gener^il franiework describing 
the processes used to develop and itiaiutiiin software. Like 
any model, it lequires interpretal ion to be used in a specific 
context. The approach used by C-MM is to describe the prin- 
ciples and leave tlieir implementafion up to the managers 
and technical staft' of each organiziition, w^ho w40 tiiilor CMM 
according to the culture and the experiences of tliek own 
envirormienh 

Perhaps the most well-known asjiect of tiie CMM is its de- 
scription of five stages, or maturity levels, of an < organiza- 
tion's software process (see Fig. 1). The first level of tiie 
software development process, referred to sunply as the 
iiiftiai leveL is described as ad hoc, poorly condolled, and 
often viitii unpredictable results \i\ tenus of schedule, effort, 
and quahty. At level 2, the repeat able leveL the outputs of the 
process are consistent (in terms of schedule, effort, and 
quality) ^ind basic controls are in place, but the pn>cesses 
tJiat produ£:e those results are not defineti or understood, 

' SEl fs sponsored by the U.S. Department of Defej^s^ and was estab]^stl8d m 1994 by ttie US. 
Congtess as a federally funded research organ j2atmfT its mission is to provide leadership in 
advancrng the state of the practice at software engineen'ng to impfDve the quality of systems 
that depend on software. 



Optimizing (Continually Im proving PtO€BSs]i 

• Pioc ess C h a ng e Ma n a geineiit 

■ Tecfifiology Change Management 

■ Defect PfGvenlion 



Level 4 



level 2 



Managed {Predfclable Prftce&s) 

# Soflwafe Quality Management 
~^ flua ntitative P rn c ess Ma nage mc nt 



Defined [Standard, Cnnsi stent Process] 

■ Peer Reviews 

■ Software Pmducif Engineeriitg 

# tntergroup Coordina:tion 

# Integrated Software Management 

# Training Prngrnm 

# Organisation Process Oelinition 

# Organization Pracess Focus 



Repeatable ^ Disciplined Process] 

SoHware Cnnfignration Management 
Software Qiialitv Assurance 

# SoJ^ware Subcontract Management 

# Software Project Tracking and Oversight 

# Software Pro j ec t P la nni ng 
^ Reqitirements Management 



rniriar|Adlfoc,Chaotrc) 



Managerial Pfocesses 
Technical Processes 



Fig. 1. Tlie Qve It?vels of llie Capabiliry Maturity Model (CMM). 
Ttie items listed at each level are called key process areas. Tliege 
areas determine sn orgaiii^tion*s software deveiopmetit rTmiuriiy. 
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Level 3» the define level, is the point at which the software 
engineering practices that lead to consistent output are 
knowTi and understood and are used across the whole orga- 
nization. The managed level, or lev^el 4, is where the defined 
elements from level 3 are quantitatively instrumented so 
that level 5. the optimizing ieveJ. can be achieved. Level 5 
exists in organizations in which the development process 
operates smoothly as a matter of routine and continuous 
process improvement is conducted on the defined and quan- 
tified processes established in the previous levels. 

Thus, CMM is seen as a maturity or groTftth model in which 
an organization works its way up tlie fi\ e levels and even 
after ha\ing attained level 5, is still in the process of contin- 
ually improving and maturing. 

Each of the five levels is also defined by the key processes 
associated with it. There are !8 key process areas that make 
up the five levels (see Fig. 1 ). These processes were chosen 
becatise of their effectiveness in improviaig an organization's 
software process capabihtj^ Tliey are considered to be re- 
quirements for achieving a maturity level. 

Managerial processes are those that primarily affect the way 
management operates to make decisions and control the 
project. Technical processes are those that primarily affect 
the way engineers operate to perform the tec hnical and 
engineering work. 

CMJVI pro^ddes a structure for each of the key process areas 
(see Fig. 2). Also, each key process area has one or more 
goals that are considered important for enhancing process 
capability. Fig. 3 shows the goals for three of the key process 
areas in level 2. 
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Fig. 2. Tho elerntMUs ihai. make up Q;e strijcturf^ of tht tt vel 2 ke> 
process ares: Software Project Piaiuiing. Each key p^oc^ess area has 

a similar sr-r of einmr-nts. 



Level 2: Repeatable. Basic imt^ject iivan^eoiervt processes are establrshed m 
track C054. schedule, and funciionafity- The necessary pfocess discipline rs in 
place to leptBi eaiiief syc cesses on proiects with similar applicatio>iis, 

{Requirements Manaf emettt 

1 Requirements are comrDlleil in estahlislt a b^aseline for eitgineeiing 
and managemenl use. 

2. PUns, pf o<f iicis. and acirvttles a^ ke|il coitsiMeai wllb die requiremeft^ 

Software Fmject Planning 

1 . fstintates are tfucumeTrted fur use in plannmg and traekhig. 

Z project acttviiie£ and comntitifienis are planned and ifocttmented. 

J. Affected groups anil imfrviduafs agree to Uieir comntitmems refaied 
ti} the pf ojecl 

Software Proieci Tracking 

1. Actual results and performances are tracked agairtst lt»e software plans. 

2. Corrective actions are taken and managed io closure when 3Ctudt 
results and pedormance deviate significantly from the plans. 

3. Changes to software commilments are agreed In by the affected groups 
and indivtduals. 



Fig, 3, Til e list of goals for ihree of the key process areas for 
level-2 CMM compliai^ce, 

Finally, each key area has five common features or attributes: 

• Comtnifmmf to perjm^Ji describes the actions needed to 
ensure tiial the process is established and will endure and 
tyi^icaHy involves policies and senior management sponsor- 
sMp. 

• Ability to petfarm describes the preconditions that must 
exist in the project or organizarion to implement the soft^ 
w£ire process competentiy. Ability to pertbmi typically 
involves resources, organizational structures, and frainitig. 

• Activities peifonned describes the roles and procedures 
necessary to implement a key process area. These typically 
Involve establishing plans and procedures, perfomnng the 
work, tracking it, and taking corrective actions as necessary. 

• i\fea.siireme}U und afialysis describes the need to nieasme 
the process and analyze the measurements. 

■ Vmiftji:ng impiemenUiiiou describes the steps needed to 
ensure that !hc acti\itics arc |:>crformcd in coinpliimcc with 
the process that has been established. Verification typically 
encompasses reviews and audits by management tmd soft- 
ware quality assurance, 

Tlie intent of CMM is to describe what needs lo be done to 
fleveiop ;nid maintain software reliabiy and welt not how to 
do it. CMM further describes practices that contribute to 
satisfying the intent of ibese attributes for each key process 
aiea. Any organization can use alteniattve practices lo ac- 
complisb the CMM goals. 

The Challenge 

Jl usiinlly takes most organizations about two to three ye^rs 
logo from leveM to lcveI-2 CMM compliance. However, 
l>asefl on very sound business reasons, our general manager 
al HP's Soft w^are Fiingineering Systems Division (SESD) com- 
niittefl us to reat hing level 3 in ^16 months. To show a com- 
mitment to Ibis aggressively scheduled task, three people 
were assignetl to the project. 
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DuriBg the planning stage, we discovered Chat because this 
was such a reasonable program, we fonld f or?ii.)lete level 2 
in less than 12 months with less than three full -lime people. 
Perhaps more important, we foimd that this program could 
provide iimnediate benefits. 

In this article we describe how our i>rodui:i I earns reached 
level-2 CMM comphance within a few months of starting the 
project, bc^ginning vtith investigating the projeel in Sejitember 
and continuing with implementation in Noveml>er 1^*94. 
By May of 1[J95 we had completed two deployment cycles 
with the product teams, imd our internal audits of the teams' 
processes verified ttiat we were operaling at level'2 f MM. 
After several more audits of all tlie profiuct teams, we found 
that tlie organization was operating at \0(Bit level'2 CX'M by 
August 1905. By May 1996 SESD ha<i taken m^or steps 
toward achie\ing level *^ and is on track to achieve level 3 
m 36 months. We expect that our description of how we 
accomplished this will provide insiglit lor other orgatiiza- 
tions trying to aehie\e similar improvement in their soft- 
ware development processes. 

The Improvement Project 

HP's Sofhvaj'e Engineering Systems Division fSESD) pro- 
duces UNIX^-' software development tools, including Soft- 
Bench, C. C++, COBOL, ITM/X, HP Distributed Smalltalk.^ 
and configiu-ation management tools. At SESD. softwaie 
engineers work together in cross-functional teams of 10 to 
15 engineers. The cross-functional teams are made up of 
represenUitives from R&D, mtu'keting, ^md learmng products. 
Tiiese teams report to twf> business leajiis, one for the tech- 
nical market imtl one for the commercial market, A combined 
Quality' and protlucthity fiuiction completes the organiza- 
tional picture. 

For several years SESD has attempted to chatige and unprove 
its software engineeiing process. However, hke most organi- 
zations the di^velopment priorities were to get products oul 
first and work on improvement if time permit! ed. Usually, 
tbere was ver>' little time to work on improvement. The 
development priority for SESD is still to get the product out 
(as it should be), but tbe software engineering i>rf)cess is 
seen as ati integral piort of achieving t liat priority. 

When we began this prc^iect SESD had in place tmd in use a 
stiuidard software Life cycle, excellent softrv^^aie development 
tools, and good practices relative to configuration manage- 
ment, defect mmuigement, inspections, coding, and testing. 
SESD also bad an exceileni customer satisfaction program 
in progress, and a basic metrics collection program in place. 

However, there were still weaknesses in our engineering 
process. It took a long time to define products and our 
design process needed some improvement. Tlie hfe cycle 
was defined, but there was a lack of procedures for perfonii- 
ing work and a lack of engineering chscipline fcjr following 
defined (jrocesses. As a result products were consistently 
taking longer tban expected, product completion dates were 
missed, and many features a^jpemed in a [jroduct tbat weren't 
originally pkmned. 

There was expert help available from HP Corporate Engi- 
neering's softw^are initiative program. HP's software initiative 
program has built exTJertLse in software process aieas tbat 
are critical to software improvement, and we were able to 



enlist the help of this organization in the early stages of our 
project, 

HP's sofl:v^^are initiative group is a team of engineering and 
management ex7>erts who deliver knowletlge and expeitise 
through c*ori suiting in softwtux^ engineering praciic(\s. H'he 
software initiative tetmi works with multiple levels of the 
organization to opdmize the organization's investment in 
development capability, accelerating the rate of making last- 
ing strategic- inipFO\^ements and reducing ttie risk of chiinge, 

Begittning with the End bi Mind 

PiS mentioned above, we knew that it wouki be difficult to 
at^hieve level-;? CMM compliance in 36 months l>ased on the 
experiences of other organizations inside and outside HP, 
Our problem was one of finding a way to institute proeess 
changes in im orderly way wJtlinul adding m^jor risks to the 
product teams* execution of tlu ir projects. 

Adding to the sense of urgency were the very real business 
goals that needed to be achievefi for SESD to be fully suc- 
cessful. The critical business issues were product time to 
market and qtuility improvement. These issues were evident 
in tbe past perfomiance of the product teams in delivering 
products witliin an 18-to-24'month window and in the diffi- 
culty of delivering products that addressed m^ior customer 
salisl'action issues. Responding to these critical business 
issues ]jn>viiled rlie real endpoint mid goal tbat tbe entire 
organization could work to achieve. 

Tlie Soft Bench" product tf^ausAvhifh was the fir^l group 
within our di\ision to begin ap] dying CMM level 2, had a 
business goal of releasing an updaie in a 12-mDntb cycle, 
which would mean a (vffj-l^rnoutli reduction in typical 
cycle time. The leaiu mIsm Jiad additional goals of reducing 
tbe numlier of lines of code in the product, delivering tlirec 
mixjor custom er satisfaction enhancements and three com- 
petitive enhancements^ and fixing all m^jor customer re- 
ported problems. 

We designed tbe software imiirovement project to helij sup- 
port tbe goals of the Soft Bench [jroduct. The life cycle and 
the processes were defined to map into the objectives of a 
12-month release cycle, jirovide methods for requirements 
aivilysis and specification in a short period, and pro\ide 
aggressive management of defects dming the development 
piT>cess. 

Investigation; Ti-aining and Planning 

To evaluate oiu* current practices we used a tecimj(iue called 
a mjfiraiv pmrp.^!^ pmflh\ which was developed by HP in 
collaboratirHi witli the Soltwrne Elngineering Institute at 
(■aniegie-Mellon fTTiiversity. The process proTile is an assess- 
ment of the state of an organization's software development 
process^ identifying strengths and weaknesses, high lighting 
tJie process improvements the organization \'alues most, and 
recommending areas for chtuige, Tlie profile uses CMM as 
the sfmidard for evaluat ing the soft ware proi^ess. t "sing ques- 
tioimaires and open-ended interviews, it provides results for 
tdl eighteen of the key process areas shovm in Fig L 
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Pe«r Reviews 

Siiftware Predud En^gineering 

Intergi^^p C^ordlnatFon 

Irrtegrafeif Software Management 

Train iirg PragraTit 

DtgARizali^ii Process [MliirtiDn 

Organizaiioit Process Focas 




FullY 
Ssti^nf 



Level 2: Repeaiable 

Cenfiguration Management 

Quality Assurance 

Subcontract Managfiiiiflnt 

Frdj£ctTfai:king^ 

Proiect Planning 

Rfiifiirrenients MaTtageniaitl 




Fully 
Sat^isfied 



Fig. 4, A scifrtt-arc prnrf^ss prcjfilf 
indicating the compliance of SESD 
lo the requirenrenf-s of levels 2 and 

3 of CMM at I he time the software 
improveineiit project began. 



To complete the profile, engineers and managers in an orga- 
nization must fill in a questioimaire that is designed to evalu- 
ate that organization's software process maturity against the 
CMM requirements. The results of this questionnaire are 
compiled into a soft^^are process profile for the organisation. 
Fij^. 4 shows SESD s software process profile. 

We selected a representative group of 30 engineers and man- 
agers to participate in the assessment and, over a period of 
tw^o days, we provided a short oveniew training session on 
CMM and a two-hour period for small groups to answer the 
assessment questions. 

An example ofa tyj^ical question from the project trackini^ 
and oversight area asks the participant; 

"Does someone review the actual project results 
regularly with yoiu" section and iab noanagers?** 

1 -Almost Always 2-Often 3-Seldom 
4-Ahnost Never 5-DoesrVt Apply 0-Don't Know 

For SESD, the process profile results (Fig. 4) indicated that 
four level -2 process areas were partially satisfied and two 
areas, requirements management and suh contract mariage- 
ment, were areas that w^ere not satisfied at all. Out of the 
seven level-3 processes, SESD partially satisfied only (me 
area^ — peer reviews. These results meant that our organiza- 
tion would need to focus on implementing improved prac- 
tices for all of the level-2 key process areas, 

Afier the results were processed, we held several re\iew 
sessions with enguieers and managers to explain what the 
resuJis meant. In one of the early sessioas we asked the 
attendees to help us ident ily the henefits of improving oar 
performance in each area arid the roadblocks to achieving 



the requirements in each area Far example, Table I shows 
the assessment results from the software project tracking 
and oversight key process area. 

Table I 

Assessment Results for Software Project 

Tracking and Oversight 

Percent of Survey 
Respondents 

Survey Questions Fully Partial Not 

Are the project's phumed acti\1- 43 24 33 

ties and deliverables tracked 
(e.g., schedule, cft'ortt and 
tests)? 

Are the actual results compared ID If) 71 

to yom" estunates thro ugh oul the 

project? 

If there is a variance, does some- 14 38 48 

one take correctiv-e action or 
exfilaiji why the vaiiance has 
occurred? 

Are changes to the activities, 19 58 23 

deli ve rallies, and schedide 
discussed with the people who 
will he affected? 

Does someone review the project 18 18 64 

results regularly with your sec- 
tion and lab managers? 
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We found that the assessment process was an hnportant 
elenienf for describing the itnprovenients needed and deter- 
mining lujw we should go about making the improvements, 
h qiiiekly fonised the entire orgiiiijzalion on an improvement 
goal Ibr our software processes and provided tiie starting 
point, for getting paitieipation in plaaming what actions we 
needed to take. 

Applying the CMM Model Effectively 

One ai the critical steps in getting started was lo LUiderstand 
CMM in detiiil. CK^er a perifxi of several weeks three process 
consnltimts met daily l<j review ihe ('MM siiecifications, 
develop our interpretation of thc^ model and trimslate it into 
language that could be ajiplied wit fun our orgarn>saii(jn.* 
This was an iinpoHant ste|) because C\MM contains many 
practices that are better suited to large orgatnxations and it 
was necessary to inteniret whitOi of these practices woitid 
apply to our orgai^iKaiion. Also, during these meetings ideas 
of how best to (Sep toy these practices were developed. 

The process consultants examined each of the key process 
areas and decided what would be required to define our 
processes in a w^ay that satisfied the re«^uirenienlB rt»r level-2 
(^MM cfimphance. Several discoveries were made in the 
course of tjiis work: 

• SESD already had many process assets tJiat could be lever- 
aged to support the key process area re<:iuirenients. These 
assets were oiu- software life cycle, our fomial docun\enta- 
tion for patches, releases, and defect management proce- 
dures, and several infonnal methods of documentation for 
si>eriJlcat]ons, design, tmd testing. 

• We discovered die need for a procf\ss archil(?rfurr w^ien we 
attemjjtcd to describe what deliverables w^ould be needed to 
support the definition of our processes. A process architec- 
ture is analogous to other tyjses of engineering architectures 
(e. g-, buildings, software, haidw^ar(\ etc.) It descritK^s the 
layout of components neerled to build a system for a specific 
purpose. Fig, 5 shows the process imiiitecture elements we 
used to create pans nv al! of the (iocu mentation neetied to 
pi'ovide SESD speci ilea t ions for creating work products and 
performing software develrjpment activities. 

• Level-2 CMM permits each project team to dociunent the 
procedm'es that ip'^ill he usetl in developing products. By 
WTiting a general procedure to cover the w^ay product devel- 
opment is generally perfonned and then customizing the 
proc^edme for each project team, if necessai^, we realized 
that we could save several mf>nths of effort imd speed up 
the eventual move to level-3 C*MM, where organizational 
processes must be standaidized. 

Formal Project Piaiming and Decisions 

To give this impro\=ement project the greatest chance of suc- 
cess and reduce tlie overall risk for the jirojecl, we developed 
a formtd project [jlan co\ eilng ever>' phase of die definitional 
work ami the timing for deployment of the processes. This 
plan w los re\iew cd mui approved by the division staff before 
beginning the implementation. 

Several key decisions needed to \w made about how the proj- 
ect deliverables w^ould be designed, re\iewed, approved, and 
deployed into the product development team's operations. 

• The pfocsss consultants were o^^gl^al^y mambfirs of tti& SESD jofrwa^e tjuality asssjiafKe 
group Thev bad extensive BxpenenDB in softwiare anginsenng praciices maiiagfiinem and 
software CEmsurting. 



ElefflifllTyiBi 


Htp^9B 


PQlicy 


• Specifies whaiwftt happen 

m Sets 1 h e c u 1 tu ra 1 expeciai i o m 

« "Thai's how we 6a things aiQund here" 


Procedure 


• Specilies how it will happcit 

« A set el steps for doing something 

* Mav specrfv who does wh«t when 


Citeciclist 


• Specifies what er how in abbreviated format 
« A short farm ef procedures for easv reference or 
ve r if i c atio n of a ct ia ns 


TemiilHte 


• Specifies the corttenl or qtialtty ef what will happen 

• Proviifes ggiifance for creating necessary work products 


Tfaining 


■ Proviites Ofgamzed infomtation on processes Ihat 
indiviituals need to perform their jobs 

• Covers poiicies, procedureSn chec;klisls, templates, or 
instructions 

• May be fonnal classroom or inlormal erientatien 


Worh ProducI 


• Specifies a^ plan or results 

• Grealed as an output of applying a defined proires^s 

• h/lev need tu be "managed and controlled " 



Fig. 5. 'Hie prfxiess architectural eletTxenl,^ nnd tlioir purpose. 

Several models for process creation, approval, and deploy- 
ment were examined and discussed before it was decided to 
use a define-deploy approach itta? mapped inTo each dcvel- 
opmeixt project s life cycle.^'^' This allowed the improvement 
project team to stage the work by life cycle phase (i.e. re- 
quirements, design, implement atitm, and test). This model 
also pro\1i:l(^d a stnictme mthin which process deliverables 
could he refined and improved. 

Measuring Progress 

Met li< iris r<jr niciisurjng Ihe progress of the project needed to 
be esiahlished- The only way to do this was through auditing 
the product development teams after each m^'xjor check- 
poini. Tims, we rlecided that a thorough audit of how the 
product develof^ment teams conducted W'Ork should be 
done after clieck|>oints when the pressiu'e to complete the 
checkpoint had suhsided and tlie team would be more open 
to listening to the audit finLhngs. Tliese findini^s were re- 
vdew'eti witli the management It^atn and any nuyor issues 
W'Cre adtlressed by iissigning owners and develop! nj^ aclion 
plans. The results of the audits were simimarized antl pub- 
lished within the di^^sion to let everyone understand the 
accomplishments of the progriim. 

Measurement of progress in each key process area was per- 
fornied by interviewing project team members and using a 
checklist of requirements for that phase of the project. This 
checkhst w^iis based on die practices needed to satisfy the 
goals for each of the key process ai-eas that apply to level-2 
CMM. 

From |jre%ioiis experience^ we realized that commimication 
would play an Lnt reashtgly impon^int role for the [>roject's 
success as new procedures and sutsporting documentation 
were developed. We decided tiiat all of tlie documentation 
would be integrated into tlie software Me cycle so that there 
w^ould he just one place to find the information. Secondly, 
this docimientation would all be online iuid the Mosaic 

' A define-dsplflv spiWDach means ihat the protrsssBs are defined m the project team just 
befofe appficatrcm This allows processss m&ded far the requifements phase to be defined 
and (leplcryed as the requirerments phase of The prDJeci fS axecutfid 
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browser conpled with our configuration management tool 
would be used to store and control the documents and pro- 
vide an easily navigable interface for users. 

Implementation: Managing the Change 

Getting an organization to adopt the changes necessaiy for 

level-2 C^tN! compliance was an important step in imple- 
menting our new processes. Defining the new policies and 
procedures and then providing training in these new txilicies 
and procedures was necessar>^ but not sufficients Changing 
the processes invoh^ed changing the culture, and this is 
where it was critical to get ever>'one thinking about the 
changes in a positive way. We approached tlus as|>eci of 
change management by deciding we would try to accom- 
phsh the following goals: 

• Demonstrate success i^ith a phased approach 

• Leverage existing proce^es and minunize some areas of 
change 

• Make the contributions of eveiyone very visible. 

Demonstrate Success with a Phased Approach 

The softvviire iinjrrovenieni jjroject needed to show results 
as early as poysil>le to capture the attention of the organiza- 
tion and to keep things focused on process improvement. To 
accomplish the objective of sho\\ing results early, the deploy- 
ment stages of the improvement project were designed to be 
about three months each."^ This tacdc provided visible re- 
sults and feedback to the organization by coinciiiing with 
the hfe cycle phases of the Soft Bench product. 

Tlie implementation stage of the improvement project con- 
sisted of a series of shoil steps for defining, reviewing, and 
approving I lie policies, procedures, and tonrplates before 
deploying them to the product development teams, Commu- 
nicating what was expected, desc ribin^^ chmiges from the 
way we used to cio things, and providing grouj) or individual 
training in new tnethods were ver>' importaiU steps in fhe 
way we depl*)yetl the t>ro<'ess changes. We knew thai Ihp 
project teams needed to unrlerstand the rules early so that 
the project could j)rfHeed smoothly. 

An ExampJe: The Requirements Phase 

During the rcquiiTments phase of the product life cycles the 
key process areas we worked on were practices for require- 
ments management and project phmninj?. By using readily 
aviiilahle customer survey data, stniclurcfl procesSi\s, mait- 
agenien! review milestones, and trtiining, we were* able U> 
rerhice the time for the requirenu^nts ph;ise from what was 
historically a six-tf>-eight -month process t^> three months. 
For the Soft Bench teams, it wjts im]K>rtant lt> gain a deeptT 
understajithng quickly of the new fcatiues demiuuleti by our 
customers and to translate this infomialion into work steps 
that would be needed in the design ph£LS(\ 

One of the problems the teams faced was reilu< ing the list of 
possible things to at^complish to a few lugh-impaci require- 
ments that coiilfl Ik* accornplistied vvithin the srliednte. Tims, 
to collect requirements infonnatiotu survey (|ueslionnmres 

' Deplov^ent was a teim we used IQ mean cornmunicarmn, tram Ing. and corrsufting wih ihe 
fjroduct d&yeiopfnecit teain, followed try apptjcatian of ihe pfocedures or lempfgies by ihe 
engirmers and managers Templaies lionsiuied of the siryctuied outlines Inn he work products, 
mKh dn disjgn spocif icaliDns. test pFans, data $hm% and so on 



based on a user-centered design methodology were created 
to facihtate rapid feedback fi'om customers using telephone 
siu^ eys. The process consultants designed stanciard tem- 
plates for the ei^jineers to describe the customer require- 
ments and the Mosaic bro^^ser was used to post work in 
progress, allowing managers to review the work. Fig. 6 
shows a portion of one of these templates. 

One criterion for determining what new teatm^s to include 
was an estimation of the resources and effort needed to 
design the iww features. A standard procetlure was provided 
for the engineers to do this (Bg. 7), These estimates were 
then available when the managers needed tJiem for decision 
making and for the engineers to do more detailed planning 
of the design phase activities. 

The declsioti making process was essential for narrowing 

the sc^ope of tlte project and finalizing the v^ork conunit- 
ments for the next phase of the product development, 

Aji Example: The Design Phase 

Diuijig the design ptiase of the product life cycle, the key 
process areas were the practices 'm project tracking (i.e., 
managing and controtling work products, especially changes 
in requirements), and in project planning f<5r the next phase. 
The success in a|:>pl>ing the software life cycle iiml CMM 
level -2 processes to this phase of tlu^ work was evidetu from 
two m^or acconiplishments. The first was that the team 
completed everv' aspect of the design work, including re- 
views and inspections, in three months. In the past* design 
specifications and design reviews were cut short l>ecause of 
schedule pressures, Ttie team was also alile to imd<e deci- 
sions eiwly in the project aboiU ellmtnating features that 
would hv too costly to implenienK For exam file, unit testing 
(\ipatnhty was a feature considered for the p!o<kict, but it 
was eliminated during the requirements phase because of 
staffing trade-offs. Hiis a<iion suhstaiUially reduced the risk 
of schedule sli|>ija^e later on. 

Leverage Excellence to Minimize Change 

As mentioned earlier, dining the assessment and planning of 
the im|>rovement jiroject. we recognixecl that many pra^^tif^es 
usihI l)y SESI) were already at leveI-2 (.MM comijliaiice. 
Tlu^refore, it was important to leverage as rtiany of the cur- 
reni pn^ictif^es mid procedure's to minin'iize the effort required 
and rechice the amount of change being Ini roduced. We 
alreafly liad a standard software life cycle defined and in 
us*\ ati t^KceUtmt softwai-e developmt^nt toolsel, and gofid 
l^ractices find tools in configuration nuuKigement. defect 
inanagenu^nt, inspeci IojiSt coding, iuid lestitig. F*art of our 
simulard (it>eraiions included a custf >mcT satisfaction surv^ey 
and software metrics. Tliese were all areas that were ac- 
knowle<lged as excellent and tival should he maintained and 
supijorted. 

The development envinjnment consisted of a suile of tools 
integrated with SoftBeiu-h. UIM/X (aser interface Motif) was 
used as a rapid ijrototyjnng tool Soft Bench provided the 
framework for editing, comi*iling. and dehugging the code, 
fapahilitics in Soft Bench were also being used to assist in 
program imderstanding through call grajihs and documetUa- 
tion f>f object-orienHMl dt^signs for the m*w features. hile- 
grated into StdtBi'Ucli was a eonfiguration managejiieui tool 
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SattB^nch 5.0 Written Survey 
Environment: 

1. What cornputer sYStems da ^oii use for saftwafe tie vela pfnent? 
Make/Model/MeniDrY , . - 



2. What types t}f operating s^vst^>"^ da you use for softwafe ilevclopTneitl 
and tfeploymem? 



Operating 
System 

HP-UX 
SunOS 
Sun Solaris 
PC Windows 
Other 



Saftwsre Develepment Software Deployment 



3. What tools do you and others in your leam use lor software 
tfevdopment? Where appropriate, please inclade a vender name. 

Requirements gathering 

Analysis 

Design 

Imptementatron 

Understanding code 

Editing 

Compiling 

Debugging 

Testing 

Conf i guf at i q n man a gemeni 

Project m a nag em e nt 

Release 

Other Itey tools 



4. What languages are used in your work group, In relative proportions? 
Please make answers in a column total 100%. 



Language 



Today 



In 12 Months 



C++ 


, % 

% 
% 


% 


COBOL 


% 


Fortran 


% 


Other 


■^ 




■V. 



In Z4 Months 



5. Oo yoif do have a mixed'taitguage development? [ J Yes [ j H(i 
If so. in what languages? 
Vour Taslts: 



G. What type of soHware do yoir develop? 

7. Oo you develop programs, libraries, or both? 

8. Whai are the major tasks yoti perform witli regard to software 
development? 

9. What tasks have yoii recently completed? 
1€. What tasks are you currently working on? 

11. If you use SoftBench, what (asks do you use rt for? 



Edit 

Compile/Buttd 

Debug 

Performance Analysis 

Comparing/Merging Files 



Static Analysis 

Code Generation 

Conhguration Management 

Mail 

Toot Iniegrarion 

Other 



12l About how many lines of code are in each of the pFograms or fibraries 
you develop? indicate the number of programs and libraries thai you 
have in eacli of the following categories. 



Sire 

<10K 
II^^K 
51-1 OOK 
101-30aK 
>300K 



Programs 



Libraries 



Fig. 6. A ptjrtifin of a template rontainiiig a survey that tlie SoftBoiK'h firri(iiii't te.m^ used to solicit customer requirements. 



(SoftCM) for managmg source code, aiid the al>ility to ac- 
cess our defect tiackiiig tool DDTs from QuaJ Track. Having 
these tools already in place and used by the engltieers was a 
nii^jor factor in maintaining developer productivity while 
making process changes in other areas. 

Inspections and software nieirit s were already a well-estab- 
iished pait of our culture. Althotigh both of these areas are 
elemetits of levei-3 CMM ar^d we were workii\g on level 2, 
we used them an^-vt^ay because we did not want to lose the 
benefits we were achie\ing \\dth these practices. Because 
itispeetions and metrics (defect tracking, schedule sUppage, 
and effort repoiling) were uistiti^itionalized in our engineer- 
ing and project management practices, we recognized tlrnt 



this would be a distinct advaiitage for us when we went to 
levels CMM, 

There were other opportimities to minunize change. These 
were in the areas of software configuration management, 
software quality assiuance, and subcontract management . 
The first two areas needed only minor changes to be level -2 
cootpliant. Our practices in these areas were robust enough 
but needed to be docimiented, with better definidons of 
roles and responsibilities. SESt) wasn't doing any software 
subcontracting, so it was decided to leverage a best practice 
from within HP to dociunent a starting point for future use. 



ToDl/CEimpDn|!itt 


External SpeciFiqatiofi^s 


Internal Specif icAtfons 


Size Estrmate^ 


High level 


Proti^type 


Final 


High Level 


Low Level 


CuTTent 


EslJmffted 


A 


mmydd/yy 


mm/dd/yv 


tnm/iid/yv 


miiVdd/vy 


mm/dd/yy 


<fiKr4CSS> 


<ii KNCSS> 


B 


mmliiJJYV 


mm/dd/yy 


mm/ft i^yv 


mn^dd/yy 


mnVdd/yy 


<eKMCSS> 


<nKNCS$> 



n KNCSS = Number of KNCSS [Theitsand Lines of Noncomjnent Source Statementsl 



Fig. 7, A template for pngirteers 

to estiiiiat.e the dociunemation 
delivery dat f?s and code size of 
new software t:ompoi\etnt5. 
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MaiirlQiibibtitioits Visible 

Managing change n?qiiiiTes good commtmication of the change, 
acknowledgment of the progress made* and encouragement 
toward the goal. After each product life cycle checkpoint, 
the software qualitj* assurance teant performed an audit by 
mieniewieg the prodiirl team memliers using a checklist 
for level-2 requirements. The sofTware quality assurance 
members were actually the process consultants from SEL 
They were able to bring experience and maturity to the au- 
dit interviewing, rpporting. and folio w-up consulting. Fig. 8 
shows portions of the checklist for the reciuirements phase. 

These audits had several m^jor benefits. First, the project 
team knew aliead of time that a process The>" used during a 
phase would be objecti\'ely evaluated by an independent 
team. This had the effect of ele\'ating the importance of using 
a defined process. Second, the audit interviews iiricovered 
critic^ issues and risks for the product's development that 
were almost always a result of deviating from the project s 
plan or processes. 



Checklist SQA frojOGt Audit Plan for Requirements Phase 
Templatfl 
Requirements Manage me ni Checklisi 

Re$poi>$ibiiitiesi were assigned tar develnping an4 anBly^ing 

requkements. 

Staffing was suffideni for developing and analysing requirements. 

Adequaie training and tqc^ls were provided for developing and 

analyzing requirements, 
__ Requiremenis are documented in ihe preiect data sheet. 

ReQuiremenls were reviewed by effected indivfdu&Js and groups. 

h sue s re In ted 1 □ req ni rn me nts we f e rep orted ci nd 1 r b c ke d . 

The proiec^ data sheet was reviewed and approved according to a 

dncumenled procedure. 

Pfoiect Planning Checklist 

Responsibilities were assigned fonhe planning requirements phase 

activities- 

Staffing was sirfficient for planning activities. 

__ Adequate training and tools were provided lor planning aclivities. 
Requirerrient phase aciiwilies were doctimenied in a requirements 

phase p^an, 
Estimates nf sqhednle were prepared and included in the requirements 

phase schedule. 
A sfiftware life cycle was identified or dpcamented in the reqtiiramfnts 

pjan and the design phase plan. 
_ Work products lor control o1 the project during the requirements phase 

were identified \n the project planmng documents. 
Qommitmenls were negotiated witli the business team managers and 

ether affected groups, 
External csmmiiments were reviewed amf approved b\ the business 

team mar^agers. 
Responsibilities were assigned for developing am} maintaining the 

design phase plan 
Adequate training and tools were provided for planning the design 

phase. 
A design phase plan was prepared according to a documented 

procedu^re. 

Design phase activities are documented in tiie design phase plan. 

_ £sti me tes of si ze. eft □ rt. a n d c o st for de s Ig n p h as e p I a nn in g we re 

prepared according to a documented procedure 
Risks were identified in the design plan and contingencv plans were 

developed, 
_^ Reqitirements are traceable in the design plan. 
^- Issues relaied to design are reported and tracked. 
— Design phase plans were updated to reflect changes in requiremems. 



Fig. 8* ['f»rtJf)iis> tjftho autiil fiif^cklist for liin roquirtHTU'iif phasr*. 
Tlii'sf' r|i» I t;]ists w(^re used to assc^ss the SESD lif** cycle aM^iinsf 



For example, during the audit we identified a problem witii 
inadequate staffing for test planning activities. TTie project 
plan caDed for the completion of test plans before design 
was finished. The audit found incomplete test plans for the 
contoxi feature changes before the design complete check- 
point. This introduced additional schedule risk because the 
schedule and staffing were not accurately estimated. It 
turned out that this part of the project was ac!iiaJly critical 
path during the implementation and testing phase. 

Tliese issues and risks were reviewed by the management 
team and derisions were niade to take corrective actions. 
Tliis had the effect of identilying tangible contributions of 
the leveJ-2 model. 

Key Results and Benefits 

Tlie improvement project to ac*hie\'e level-2 CMM has had 
se\eral threct results. Fh^st. liie cycle time for the SoftBench 
release wiis reduced from 18 to 24 months to 14 months. 
This resulted in a sigiuTtcant reduction in engmeering time, 
and consequently, a saving in the cost of developing the 
product. Wliile the 12 -month release cycle required a little 
longer than planned, the commitment date at the time of 
design completjon was met with no schedute slit> antl no re- 
duction in product reHabiht^^ standards- Across all of SESD's 
products there was a reduction from an average of 4.6 open 
serioiLs defects at manufacturing release in lf*94 to 1.6 open 
serious defects per protluct in ] 995. In fact, the product 
team frsed all outstanding mayor customer service requests 
during this period, In addition, the product team reduced the 
overall fotitf" si;^e by 12'Ki, reduced documentation si^e by 
35%, and (j«^livered three ma^jor customer satisfaction im- 
provements atid three m^^jor competitive improvements. All 
of these are, of course, significant business restilts coming 
rrnrn Ihe levei-2 CMIVI process. On SoftBench alone there 
was y cost rethuiion of two million dollars per year, or a 
return on investment of approximately 9 to !. 

Other results of t[ie improvement effort arc that all of the 
product relciises in 1995, which also met level-2 CMM conv 
pliance, were completed in under 12 montiis witi^i no sc^hCKlule 
slip Rg. 9 sho^^^y die cycle rttnes fc jr similiir projwts twer tite 
IJiist fi\ e yctus. Tlie average tycle time for tiie 1995 (>rtjjetis was 
9.8 tiK>n1ks. whicli is a 4Bh iiediiction in c>cle liitie fvtym tiie 
ninnutg a\<*rage of 18 moiidis for piTvious yeiirs. Tlie schedule 
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estirnation em>r (fiftim desii^ compktioTi to project completion) 
was reduced to zero during U)95, compared witii mucii tugher 
erroiB in previous years. 

Improved Execution. In past projects, the investigation phase 
usually lasted from 6 to 12 months, mainly because of the 
unstructured, e5q)loratory nature of the process used. By 
adopting a formal structure (i.e,; tasks and schedules), the 
investigation phase was reduced to four months. 

Given the 12-month release cycle, it was critical to meet the 
intermediate phase deadUnes to keep the project on track. 
In past projects^ these rnHestone deadlines were consistently 
delayed by moitths. As a result of the careful plajuiing and 
tracldng processes used, the SoftBench team was able to 
meet the checi<point deadlines wltJiin a very narrow margin 
of error (i.e., a few weeks). 

Customer Orientation. Historic ally, oiu- product requirements 
process had been focused on prototyTping features and func- 
tionEihty that engine eis identified through an infusion of 
"next bench" ideas. Product marketing would test these 
ideas with customers and use this feedback to select the 
best set of features to uiclude in the next release. Eveiyone 
recogriized the limitations of this approach in getting fiesh 
ideas iuid direction for a product. Process improvement 
efforts were imderway to de&ne a user-centered design pro- 
cess that would really focus on what customers had asked 
tor. The niiyor change that occiured as a result of adopting 
the level-2 CMM practices is that we forced ourselves to 
adopt a new paradigm hi the way we acquired imd evtiluated 
customer input. 

The Abilitv to Respond to Changes. In most of our earMer proj- 
ects, w^hen changes m requirements or personnel occmred, 
there would be several weeks of confusion before re\ispd 
plans or schedules could be started. In the new model of 
project management and level-2 practices, when a change 
occurs the management team knows that replanning must 
start inuTiediately. Operating at level 2, the SoftBench team 
was able to estimate the impart of proposed changes and 



then schedule the time for engineers to replan and estimate 
the new schedule. ^\Tken this occurred, we did not have the 
usual confusion about what to do. Instead, the team was 
able to respond with confidence and with very httle lost 
time. 

Conclusion 

We believe that our circumstances and development envi- 
ronment aie not unique. Many other (Organizations are trying 
vaiious quality improvement programs for software devel- 
opment and finding it very difficult to make the changes 
necessary' to be more rigorous tmd disciplined in their engi- 
neering practices. We also believe thai we have discovered 
many of the essential ingredients to make a software im- 
provement program succeed in a very short period of time. 

Oui* work at SESD [las convinced us that the Capability 
Maturity Model from SEl provides an excellent framework 
for defining software engineering process improvement for 
a small software organization. Achie%Tng level-2 status has 
largely been a matter of estal)hshing a direction with leader- 
ship from top managen\ent. and then instituting a credible 
program for improving the practices used by sofrwarp proj- 
ects in plamiing and managitig the work according to the 
CMM giddelijics. We beUeve that other organizations can 
achieve similar results in one year if leadership and execu- 
tion of the software improvement project are a priority for 
the management team. 
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Software Failure Analysis for 
High-Return Process Improvement 
Decisions 



Software failure analysis and root-cause analysis have become valuable 
tools in enabling organizations to determine the weaknesses in their 
development processes and decide what changes they need to make and 
where. 

by Babert B. Grady 



When I was growing up, my father was fond of using sayings 
to eEiC'Ourage mt? to reii\ ember important lessoiis. One of his 
favorites was ^'Do you faiow the difference between a wise 
man and a fool?*' He would then go on to say thai a wise man 
makes a mistake only once, A fool makes the same mistake 
over and over again. 

Applying my father*s saying to softw^are defects, it some- 
times seems as if there are many *'fools" among software 
developers. However, tiiere aren't. Individually, they J earn 
from their mistakes. What's missing is organizational leaniing 
iiboiit our software mistakes. 1 guess that many oi^^aiiizadons 
have earned my dad's '^fool" lal>eL 

One useful way to evaluate software defects is to tiaiisfer 
process learning from individuals to organizations. It in- 
cludes not only analyzing software defects but also brain- 
stomiing the root causes of those defects and inc*ori>orating 
what we ieani into training and process changes so that the 
defects won't occur again. There are five steijs: 

1, Kxlend defect data collection to include root-cause infor- 
t nation. Start sliLfting from reactive responses to defects 
toward proactive responses. 

2. Do failure analysts on representative organization -wide 
defect data. Failure amdysu is the eviitMation oj defect 
pat terns to kam process orpmduct imaknesses. 

Ik Do root-cause analysis to help decide wiiat changes must 
be n\ade- Root-rauJif anaiijsis is a group n'ti.sotiing process 
(ipplicd fo flrffx't iiiJoiinalioH to develop onfamzational 
undersfamiiug of (he catties of a pa Tiiciilar class €(f defects. 

4. Apply what is learned to train people and to change 
development and maintenance processes. 

5. Evolve failure analysis and root-<'ause analysis to an 
effective continuous process improvement process. 

How flo these steps differ from other popular methods for 
mialyziu^ pro(x^sses? One popular- method is process assess- 
ments, for exampie, SEI (Softwaie Engineering Insritute) 
[jrot^ess assessments.' Most assessments donuucrii peoples' 
answers to subjective questions diat are designed around 
s^imebody's model t>f ideal software develo]>ment practices, 
if such mudcLs are accurate and if peoples' answers reflect 



reality, the modSlif |»»^de a good picture of an organiza- 
tion's Stat as. Thus, tlve results may or may not be timely 
representative, or motivational. 

The combination of failure analysis and root-cause analysis 
is potentially more valuable than subjective assessments, 
because it quantifies defect costs for a specific organization. 
The key point to remember Ls that software defect data is 
your most impt>itant available maiiagement infommtion 
source for software process impiovement decisions. Fiuliter- 
more, subsequent data wiU provide a measurable way of 
seeing results and evaiuatmg how- methods can be further 
adapted when a specific set of changes is done. 

Reactive Use of Defect Data (A Coninion Starting 
Point) 

After iuilial analysis, everyone reacts to defccis either by 
llxijig tliem or by ignoring them. Customer dissatisfaction is 
minimized when we react quickly to fix problems that affect 
a customers business, Tliis is often done with fast respoiise 
to issues and by following up with patches or workiirotmds, 
when appropriate. Stjme Hewlett-Packard divisions track 
tiie resohjtion of "hot. sites." Fig. 1 shows an example.- Such 
a chart is a valuable way to track responsiveness, but it does 
little to prevent future defects. FurUteiTUore, hot sites and 
pau ii nianagerueui. are very expensive. 
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Fig. 1, Traekiiig the nmnber of hot sites during any partitiular week. 
Fin exHiiipk*, for the vve€*k indtC'ated then* were M- N hot sires Ltiat 
IkuI itpph hot tor ri jojig Ujiie and N hot, sil(*s l\\ii\ had been hoL for a 
sJiorl Mrllf^ ti 1D92 Prentice- Hall used with ptTiTussioii. 



AiigiLsj ilMJGJkwii'ft PackEucLJiJuriiiil 15 



)Copr. 1949-1998 Hewlett-Packard Co. 



II 



120 J 
30 - 

30 

-30 
-60 



Service Requests or Qtscrepaitcy 
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Fig. 2. Incoming mamtenance requesis, clcfsed iiminlenance 
requests, and net progress for one NASA project. This figure is 
reprinted by pennissign uf the public] ler riuni "A Sollvvare Metric 
Set for Program Maintenance Managemejit," by G. Stark, G.L. 
Kem^ and C. Vo\w^l\,Jaun7al of Systems and Soft ware, Vol 24. 
p. 243, ©1994 by El'3e\1er Science Iiic, 

Cumulative defects for long-lived software products are also 
tracked. For example. Fig. 2 shows the incoming service 
requests or cilscrcpaney reports, the closed ser%ice requests 
or discrepancy reports, and the net progiess for one NASA 
software project.'^ Some HP tiivisioiis also track progress like 
this,^ althougli HP's progress measm-c sal (tracts incoming 
defects from c^iosed defects so thai positive progress repre- 
sents a net reduction in defects. NASA appears to do the 
reverse. 

Both the liot site grapli and the defect closure progress 
graph show reactive uses of defeei data. In the examples, 
the respective organizations weie tjsing the data to try to 
improve their immediate customer situations. The allenm- 
tive is to ignore the data or to react much more slowly. 

Ignoiing defect data can lead to serious consequences for an 
organization s business. For exanifjle, the division producing 
one HP software system decided to release its product de- 
sx>ite a continuing incotning defect trend dining system test. 
Tlie result was a vei7 costly update shortly after release, a 
continued steatiy neeti for defect repturs, and a product with 
a bad quality reputation. This is the kind of mistake that ctui 
cause an entire product line's downfall. A recent article de- 
scribed how one company letui^ed this lesson tlie hard way^ 

Responses should not be limited only to reaction. Besides 
endangering customer satisfaction and increasing costs, 
here are some other dangers that could occur if reactive 
processes aren't coniplemenletl witli proacUve steps lo 
eliminate defect sotnces: 

i. People cati get in the habit of emphasizing reactive think- 
ing. This, in turn, suggests that niajtage inept fit it is si tipping 
defective products acceptable. 

2. Managers get in the hai^it of pnmartly rewarding reactive 
behavior. This further reenforces fixing defects late hi devel- 
opment or alter release. Late fixes are both costly and dis- 
ruptive. 

3. People place blame too easily in higlily reactive etniron- 
nients becatise of accompanying pressttre or stress. This is 
demoralizing, since the root causes of most tlefects are poor 
training, docmiicntation. or processes* not individual incom- 
petence. 



Remember that effectively reacting to defects is aii important 
part of successfully produchig soflW'are products. However, 
because bttsmess conditions change rapidly, many organiza- 
tions can't seem to find the time to break old habits of using 
defect data reactively without considering ways of eliminat- 
ing similar future problems. The elimination of the causes of 
potential ftiture defects must be Included in any successful 
long-term business strategy. 

Failure Analysis (Changing Your Mental Frame of 
Reference) 

The proactive use of defect data to climiiuiie ihe root causes 
of software defects starts with a change iti rnei\tal frante of 
reference. The reactive frame generally focuses on single 
defects and asks "^How^ mtirli do tltey hin1?" It als<j considers 
how important it is lo fix pjirlicular defet ts compared with 
others and asks "Ulien must they be fixed?" The proactive 
frame iisks, "What caused those defects in the first place? 
Wliich ones cause the greatest resource drain? How^ can we 
avoid them next time?" 

Various repoils have desc^ jibed successful effoits to analyze 
defects, their causes, and proposed sohitions. l^ul the ter- 
minology among them hiis tUffereti, and tlte dell nit ions could 
mean different t flings to tUfferenl people, hi tlie fall of 11186, 
the HP Software Metdcs Coimcil addressed the defmition of 
standard categories of defect clauses. Our goal was to ijrovide 
standard defect terminology lliat different HP projects and 
labs couki use to report, analyze, atid focus efforts to elimi- 
nate defects and their root causes. Fig. 3 is the model that 
has evolved from om' oiiginaj defuiitions.- 

The model is used by selecting one descriptor each from 
origin, typet and mode for each defect report, as it is resolved. 
For examjiie. a defect might be a design defect in which pait 
of the user interface described in the uitemal specification 
was niissmg. Another defect might be a coding defect in 
wfiich some logic was WTong. 

Fig. 4 gives some idea of hoiv defects vary fi'om one entity to 
anotlier.' Tlie different shadhigs reflect tlie origin part of 
Fig. 3, The pie wedges conic from the niitldle layer of Fig. 3, 
tlie defect tyijes. The eigtu laigest sources of defects for 
different HP tli visions ;ue shown in eacli pie. All four results 
profile defects fotmd only dtning system and integration 
tests. 

We can immediately see from Fig. 4 that the sources of de- 
fects v;iry greatly across tiie organizaiions. No twt> pie chants 
are alike. These differences are not sun>rtsnig. If eveiyone 
developed the same way anti experience*) the same problenis, 
then we would have fixed those problems by now. histead, 
theie aie many different enviromuents. While many t}roi>osed 
solutions to oiu problems apply to different situations, they 
don't necessarily apply equally well to all problems or all 
environments. 

Some of the differences are because of inconsistencies in 
peoples' use of the origin tuid type tlcfuiitioits. Because the 
definitions are just a means to focus process improvement 
efforts on the costliest rework areas, groups resolve incon- 
sistencies wiien tiiey defuie root caiLses to problems and 
brainstorm potential fixes. It is the triggeritig of these dis- 
cussions that makes the data in Fig. 4 so miportajit. DisciLss- 
uig root causes is a way to instUl a process improvement 
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Fig. 3, Categormttion of soft^'are defeet^s. © 1992 Ffeirtice-Hall used with perniiBsioii. 



attitude in an organization. Defcct data will provide a niea- 
.surabli' biuiis for dedsioiis that must be niadt^. By t'fjjiUnuiui^ 
to track dcfec'l duia, km organiziition can also measure how 
succeysful its solutions are. 

Acting on Causa! Data 

( cjlli^tling deferi houix t* data b onJy the first stop. Persuasive 
as the data tnighl l>e, imi)ravetnentjs won't happen automati- 
cally. Both managers aJid engineers must agree on what the 
data nieaji.s ajui the intiHinmn e of aeling on it. One of the 
hest ways to lielp ensiirt* dial diis lut|>i>ens is t(* tic* proi)f}sed 
iniprovemenrs to staled business goals, 1'hisalso keeps 
improvement priorities high enough to help ensure sustained 
management support. 

Besities matiagemeni siippoii , some fLrst-liiie managers and 
enginet^i>i fdTecled by a proposec] ch^m^e must he motivated 
to <lo sometlitng and he assigneci resj>onsibilit>' to plan ^md do 
the necessaiy eluuiges. Fiuidly, as for kmy effective project, 
there must be a way of monitoring progress and gauging 
success. 

As a group, softw^ue developers now have several decades 
of software cievelopment experience. It is lime to break out 
of our pressure-driven reactive habits and use imi act uuui- 
lared knowledge to drive lasting improvements. Failiae anal- 
ysis changes the way nuinagers and develtjpers look at soft- 
wajf' (tefects, llils fnially opens tlie way to a proactive frmwe 
of r(*ferenee. 

Root-Caiise Analysis Processes 

lliere kUY many jjossif de ways to analyze rdot-eause data, 
.\ny suGcessfuJ way must be sensitive to project pressures 



anti pei^ofuiei motivation, IIP has used several approaches 
in different orgimiziitions. F'or this discussion. I will label 
three t i^it seem to evolve^ naturally from each other as orte- 
Hfiot rool'VUu^e tuiali/si^, pas f -project root-cause (umlysis, 
m\d continuous pmcess Impfwemenl ci/cle. These three 
approaches include many common steps. Since the first is 
ati inti'odticiory process, the most detailed explanation is 
saved for the post-project root-cause analysis. 

One-Shot Root-Cause Anaiysis 

A good stiuting at^firoaih for tjrganizations tliat have not 
previously categorized their defect data by rhjI causes is a 
one-shot rootni'ause analysis. This approach mininiizes the 
amourU of organizational effoit invested by using someone 
from oiUside the organization to facilitate the process. 
At IIP [uost di\isinns bavt^ defect tracking systems with 
complete enough infonnation to extract such (iata. 

The one-shot process has six steps. 

1, hitroduce a group of engineers and managers to tht! 
fail nre-imaly sis model (Fig. 3) and the root-cause analysis 
process. (About one hour.) Make it clear that the gf)als of 
the one-shot process are to: 

* t leate a rough picture of divisional defeii patterns. 

• Identify some potential improvemejU opportunities. 

2. Select 50 to 75 defects from the defect tracking system 
using a random process. Make sure tlrnt the team thinks tiie 
defects h£ive enough information to enabte them to extract 
tlte mK:e.ssary causal information. (About two hours some- 
iime before the meeting.) 
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3. Have the people in the gioup classify one defect per 
person and discuss the findings as a group, Tlieii liave them 
classify enoiigli deftMis so I hat yoii have about 50 total 
Draw a pie chart of the top eight ilefect types. (About two 
hours.) 

4. Pick two defect types to focus on. Create fishbcmc dia- 
grams from the combined root causes and adtUtional com- 
ments. A fishbone diagram is a bnunstorming tool used to 
combine and organize group thoughts.-'^ (About half an 
hour ) 

5. Develop some recommendations for improvements* 
(About half an hour) 

(5. Piesent tlie iTSiilt-s and recommendations to management. 
Make assigmnents to do itiitial changes. (About one horn) 

Participants in this process have been generally surprised 
and excited that they could leaiii so much m a very short 
time. They ha\'e also been uniformly interested in adopting 
the imalysis (>rucess fiennai^ently. flow quickly they have 
followed tlirough has \'ai1ed, depending on many business 
variables suih as iimnediate product conunitmentSj otlier 
in-progress changes, or a tight economic clinmte, 

Post-Project Root-Cause Analysis 

Tlie major difYerence between this process iuid the one -shot 
process is that organizations that start with the one-shot 



process have not previously ( tjUected t:au.sa] data. Organiza- 
tions that already col led failure-atialysis data and have an 
Lttuje I standing of their t>ai^t tlefect patterns analyze their 
tiata and act on iheir results more efficiently. The steps m 
this approach follow the meeting ouOine shown in Fig. 5. 



Premeeting: 

« td^ntify the divlston's primary btistness goat 

« Have the division champion and root-cause facilitator analyze data. 

• Have the champion send eut the meethg announcement and 
instructions to engineers. 

Pick twa delects from their code that have been chosen from the 
dated categories. 
o Think ef ways to prevent er find tfeteets sooner. 

Meeting 

• State the meeting's goal {use insights gained frem failure analysis 
[fata 10 improve developmeni and support practices). 

• Perform j^ssues selection (10 minctesK 

• Review the defects brought to the mealing US fntnutes], 

• Perform analysis (15 minutes} 

• Take a break (10 mi notes ). 

• rainstorm sotutioti^ 110 minutes). 

• Test for cemmitment [ID miimtes)'. 

• Pian for change (10 minutes). 

Postmeeting 

« Have the division champion and root -cause facilitator review 

meeting process. 
■ Have the divismn champion capture soHware development process 

baseline data. 

Fig, o. Root-cause analysis meetiiig outline. 
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Note ihm the times shown m Fig. 5 are intended to force the 
meeting to keep axo\Tng. It is best to schedule a ftdJ two 
hours, since all that time wiU be needed. The example used 
here to illustrate this process came from a root-cause analysis 
meeting done at an HP division shortly after a team at that 
division released a new product. 

PfeinoelJiig: 

• Identify ihe organizations primary business goal. This goaJ 
is an important input when prioritizing which high-level 
defect causes should be addressed first. It also helps to 
frame management presentations to ensure sustained man- 
agement support. Typical business goals might be framed 
aroutrd maximizing a particular custon^er group's satlsfat^- 
tion, e\ ohing a product lijie to some futwe state, or control- 
ling costs or schedule to get new customers. 

• The di\1sion champion and motHi-ause facilitator analyze 
the data The ciiampion is a person who promotes a process 
or improvement activity, removes obstacles, enlluisiastically 
suppons implementers anci users, and leads through active 
involvement. The root -cause lacilitaior is a person who runs 
the root-cause analysis meeting. The champion ?md tl^e 
facilitator need to be skilled at meeting processes kuid 
d>Tiami(^s aiid be familiar with software development and 
f/onnnon defect types. One simple data-analysis approach Ls 
to enter the data into an electronic spreadsheet. Draw pie 
charts of the top eight rjefect types by quantity antl by find 
^uid fix effort (either actual or estimated ). Fig. 6 sliows the 
systenvtest data for four projects at one IIP divisiott Tlie 
shading represents defect origin information, mid the pie 
wedges are defect types. Tlte lefi pie chart shows the eight 
most freiiuently recorded causes of defects. Tlie right pie 
Chan shows the data atjjusted to reflect that design and 
specificaiion defe< is found dtiring system test cost much 
more to ILx than (tiding defects do. Sinc^e tfie IIP di\ision 
that provided liiis data did not collect their defect -fix times, 
the weighting factors me based on six industr>' studies sum- 
mariJied in reference 2. Tlie light pie chrnl in Fig, 6 was pre- 

jijaivd by inuldpl>ing the left pjie chart wedge percentages 
(or counts) by the api^ropriate weighting factor and then 

convening back to 101}%. 



• Select two defect typ^ to brainstorm based on the best 
estimate of the or^amzation s concern or readiness to imple- 
ment solutions. The tw o defect types selected for this meet- 
ing were user-interface defects and specifications defects. 
TTie specifications defect t>pe was picked because it w^s 
the largest division category ( 64 out of 476 defects were 
classified as specifications defect types for tiiis project 
team), User-interface defects were picked because they 
were the largest caiegory^ f 1 10 defects) that the particular 
brainstorming team liad expeiienc*ed. Both categories repre^ 
sented significant divisional improvement opportunities, 

• Send out instructions to engineers. The organization cham- 
pion should have each engineer bring liard-copy information 
on two defects from their rode, based on the chosen tyix^s. 
Tell invitees to thiidc back to the most likely root cause for 
each defect and to propose at least one way to prevent or 
find each defect sooner. 

Meeting: 

• Stafe the meetings goal (use iiLsiglits gained from failme- 
analysis data to improve the organization's development 
and maintenance practices). Present the defect categoriza- 
tion model show topical patterns for otlier organizations, 
and show your organization s pattern. Set a positive tone for 
the meeting. Remind particip^mts that they will be looking 
at proceas Haw^s, and that tliey must avoid even joking com- 
ments diat might belittle the data or solutions discussed. 

• Issues selection. Reiterate tire reiisons for selecting this 
meetijigs pari IcuUir defect types. Let people make initial 
comments. Address concerns about potential dat^ inaccura- 
cies (if liiey come uj.^ at this point) by empliasizing liie solu- 
tion-oriented nature of the brainsiorming pro(*ess. Suggest 
that inaccuracies matter less w^hen combining pie wedges to 
consider solutions. For example, for the sample division 
meeting, some engineers had a hard lime calling some 
defects "user intoi-fiice" as opposed to "spt^t^ifi cations/ We 
simply used iMith labels for such defects during the meeling 
instead of getting sidetracked on resolvitig the differences. 
You want \x> get people ready to share their defects by dis- 
cussing a future time {like their tiext. nisuor product release) 



togic 2Q.e% 






Hardware 
Interface 7.7% — — 




Error Checking 10.0% 

y- Data Handling 10.5% 

tiser Intetf^ce tOJ% — 
— Standards 7.0% 



Weighted Data 

r 



SpecrfieatiDns2S.5% 



r interface 1t7% —^ 




Hardwara Interface Z(l% 

Softwere tnietface 5.5% 



^— Logic 7,6% 



Data Handling 3M% 
Standards 2.5% 



Specrficaliiins 52.3% 



SpecificatiQn^/ 
Reqtiirenients 



Design 



Ceda 



Weightmg Factois 

Specifications 
Design 
Code 
Doeumentati^iit 



Fig. fi. Ebp vigUi causes of defpcts tor one cJivision, 



US 
O.ZE 
25 
1 



Awgiwt t mm 1 Ic* wlmi -Par^kitnl .Utumitl 10 



)Copr. 1949-1998 Hewlett-Packard Co. 



when fhi'y will lia^e cioiie srinietlvrng in their process to 
eliminate ihe reasons for the defects, 
i Review tlie tlerect.s tirouglit lo ihe meeting. Have engineers 
read theii^ own tlefe<*ts, root causes, and solutions. Tlie m^jor 
reason 1<j do this is to get attendees involved in the meeting 
in a non threatening way. Thus, don't c^riticize tliose who did 
not prepare, rather encourage them to contribute in real 
time. Unlike ins[)ertion.s, root-t ause ajialysis meeting.'^ re- 
quiie vei-y tittle prei:)aiiitlou time for attendees. Alter their 
first meeting, attendees wlU realise ihiy, and it will be easier 
to get lliem to review theb defecis before tiie next meetii\g. 

Get in a creative, brainstomung mood by showing the engi- 
neers that all ttieir inputs are right, imtl begin to fonn a 
shared undei-standhig of tennirif)log>' mtd detlnitionH. mid an 
acceptable level of amiiiguiiy. This seciion also gives you 
some idea whetlier diere Is some etilhiisiasru lor any i>anic- 
ular defect tyi>es. You can use such energy later to motivate 
action. 

The following two examples are from the rootnesi&feliie^tihg 
held by die example HP division, lliere were ^^^^rieers 
and managei-s ai this meeting, 

L User-interface defect: There was a way to .select (data) 
peaks by haiul for another pait of the product, but not for 
the part being ai^alyzed. 

Cause: Features added late; unanticipated use. 

Proposed way to avoid or detect sooner: Walkdirough or 
review by people other thmi the local design team. 



2. Specif leations defect: CUp function doesn*t copy sets of 
otjrjects. 

Cause: Inherited code, nehher code nor error message 
existed. Higtdy useful feature^ added, liked, but never fomid 
its way back into speciflealioiis or designs. 

Proposal t:o avoid or detect sooner: Do written specifica- 
tions and control creeping features. 

• Perform analysis. Create fishbone diagrams^'*' from com- 
bined root causes and addrfiuna] ((yinmenUs. I'se ihis discus- 
sion to bring the group from I heir individual pre meeting 
biases regfirtUng defects to a group consensus state. A use- 
ful teelmique for grouping the defects is to write the sug- 
gested t. auses on movable pieces of paper. Then have the 
group silendy move the pa|)er>r inio groupings of related 
areas. If some of Ww papers move back and foith Ijeiweeti 
two groups, duplicate them. The residtuig groupings m*e 
called an ajfhiilij diagrruH.' These art^ m^jor bones of the 
fishbone that tiie gioup must name. Don't expect the llsh- 
bone to be perfect here or even complete. The next session 
will potentially contribute more. j\lso, don't get concerned 
about form. Let the group know that a fishbone is just a 
means to an end, that il will he cleaned up after the meetings 
and tliat it is likely to change even after I hat point. The fish- 
bone diagrams in Figs. 7 and 8 me from analyzing the two 
defect tji^es mentioned above. 

• Take a break. This type cjf meeting takes a lot of energy and 
focus. lt*s tiard to sustain that for two full hoiirs. 
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Fig. 8. Fishbone diagrditi ft>r the causes of specifications defects. 

t BraiiibUimi suiuticjiis, L'se this time as an ortliogorval 
approach to luialyzing the issues at liand. This is also the 
transition from analysis to action plarining for citange. 
Think about what gi'oiip energy can be tunieti utto solution 
planning*. 

For our sajnt^le tpani, there was a lot of grouj) inteiest in 
I)Oth defect types. Because a task f(>rc:e already was wxjrking 
on specification defects as a result of llie previous root-c^us** 
analysis meetings, planning focused on user-interface defects. 
In the soltJlion list tliey created, some of the soititions may 
seem vague. Remember that the brainstoiTn list is only an 
intennediate step toward defining action steps. Just be strrc 
tliat the gnnip untlerstands what it means by the solutions- 
If members seem to understand the solutions, there is no 
need to slow^ dowTi the brainstonning process for more pre- 
cise fletl nit ions. These can be atided later 

The solution list they created is as follows: 

1, Leioi! from past ex|jeiience — track user interfaces, 
particuhu ly wiien changes occur. 

2. Wven new functionality is thou^it of or added, always 
design aatd specify tiser-int efface i triplications, 

'S. Evaluate other applications, 

4. Use a checklist when designing panels. 

5, Use the Caseworks design totil. 



(i. Coitiplete cm entire featiiie wlien you do it. 

7. Give a new feature to someone else to use right away. 

8. Solicit tlioughtiul feedback. Create guidelines forfee<Iback 
and watch iisers uae interfaces. 

9. Perfomi usability walktlu-oughs and trainiitg- 

10. Use siaiuiard modules (e.g., common dialog boxes). 

• Teat for <*onmiitment. Normally there is no need fvir ttiis 
section, but sotue organizaiions dial are more tigtvtly t^on- 
trolled than o titers may not feel empf)wered to implement 
solutions. In these orgamzations, soluUotis should t>e directed 
tow'ard doing what the group feels it is empowered to do. 
Wheti Ihosc^ solutions ate sueressfuL I hey eat^ be more 
brouflly or completely applied. You may need to test to iden- 
tify tlie roadblocks to change (e.g., time, schedule, etc.). 

Our examjjle HP division seemed very com mi I ted. This was 
reinforced in the next step when several people volunteered 
to initiate specific chiuiges, 

• Plan for chmige. Discuss wliieh defects can be eliminated 
with (he proijosrd soIulir>n. Create an ar tion tjhtn wilti 
responsibilities and tlales. A model acticjn plaji miglit 
contain the following steps: 



L Esiafjlislt working group 
2. Meet iuid define outputs 



10/a 
10/15 
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3. Present objectives and gatlier inputs tl/l 

4. Create a change process and artifacts 12/1 

5. Inspect and ftc process and artifacts 12/15 

6. Celebrate 

7. Use and measure results. 2/1 

Our example division team decided to create guidelines for 
user interface designs that addressed many of its fishbone- 
diagiam branches. The division's action plan consisted of 
tlie following steps. 

1. Patty will create a checklist for designing panels. (First 
pass by 12/17) 

2. The project manager will set expectations that aU new 
functionality' wih be accompanied by design and specification 
implications. {Consider using new specification formats/) 

3. Art will give the project team a presentation on Caseworks. 

4. Follow up the project presentation with a discussion on 
the use of prototyt^Jtng, 

Hemeniber to end the meeting with a clear understanding of 
ownership and responsibihty. Use standard project-manage- 
ment techniques to pi mi and schedule follow-up . 

Postmeetiftg: 

• Re\iew meeting process. The organization champion and 
root-cause facihtator review the process and develop 
changes to meeting fonnat, data collection, analysis, and 
responsibilities. They should redo the fishbone diagram, 
being careful not to change it so much that participants no 
longer feel that it is theirs. Promptly send out meeting notes 
that mcludc the fishbone diagram, responsibilities and action 
items, and schedule dates. 

• Capture process baseline data. As part of structuring a 
process improvement project for success, someone (the 
organization champion) should record a niinimum amount 
of process infonnatjon before and after tiie projecl,^ It is 
particularly important to df)cu merit the basic divisional 
processes so that when the Improvement is done, the group 
can better understand other influences besides the particular 
changes tliat w ere made, hi this example, the team didn't 
do this step. 

Results &OII1 EHminatixig Defect Root Causes 

The team from the example division did their checklist and 
used it during their next project. It had 30 if ems to watch 
out for, based on their previous exj>eiience and tJieir defects. 
Fig. 9 shows an exceipt frt^m their checkhst. fXer 20 i>ercent 
of the defects on their previous project had Ijeen user-inter- 
face defects (though tlie ilivision-wide average was lower). 
The residts of their change *s were impressive. 

• Tliey reduced tlie percentage of user-Lnterl'ac*e defects in 
test for their new ye^ir-long project to roughly five percent 
of their total system test defects. 

• Even though the project produced :J4 percent more code. 
they spent 27 percent less time in test 

Of course, other improvement efforts also contributed to 
their success. But the clear user iuterface defect reduction 
showed them that their new guidelines and the attention 
they paid to their inlerfaces were major contributors.'^ 
Finally, the best news is tliat customers were veiy pleased 
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with the user interface, and initial product sales wer6 very 
good. 

Twro other project teams finished their projects recently, and 
their results w^ere equally impressive. Both projects used 
new sta^ndard divisional specification templates created to 
ehminate many of the root causes shown in Fig. 8, A cross- 
project team task force had created two two-page specifLca- 
tion templates (one for user-interface-oriented routines, one 
for software-interface-oriented ones) that they felt would 
help. Both teams substantially reduced specific ati on tiefects 
compaied witii their previous project levels. Wtile the reason 
for one team's reduction could possibly be that the project 
was second-generation, the other project wasn't. 

While the action steps discussed here foOow those of suc- 
cessful improvement projects at one IIP division, they can 
also be applied in organizations witii difterent defect patfenis 
and busuiess needs. One of the division people who worked 
with all three project teams summaiized their results: 
"... We must conclude that the root-cause approach is an 
effective mechanism to identify and uttroduce change into 
our software development process."^ 

Continuous Process Improvement Cycle 

Some organizations have felt that root -cause analysis is so 
beneficial that they no^v use it to pmsuc continuous j^rocess 
improvement. It appears to be a natural evolution from post- 
process root^:aiisc analysis successes. This approach ext^ends 
the supporting infrastructure and requires an ongoing man- 
age men I con un itm cnt . 

The first step that an organization generally takes is to widely 
adopt root-cause infoimation Logging by pngmeers. Causal 
infonnalinn is then included as a normal part of the defect- 
hajTdlit^g process. Analysis is triggcreti in a variety of ways, 
often by a product or system release. Sometimes it is trig- 
gered l.»y t!ie eT\d of a development phase or a series of in- 
spections. It Ciui also be triggered by an arbilrai"> time pe- 
riod. Rg. it) shows how one IIP division tuns its process. 
RooKrause solution teams are empowered by management 
to itiitiate smaller process improvements. *^ More far-reach- 
ing improvements still retjuire lab mai^agement approval. 

Knowing which defects occm' most often in test or later helps 
to focus improvement efforts. We saw two examples of this 



22 A vij?ust 1 996 Hf w] et t -Packard Joiima] 



)Copr. 1949-1998 Hewlett-Packard Co. 




Re lease -Based 
Melric;s 



Fiine- Based 
Metrics 



La rge- Scale 
Improvement 
Sifgge^ttotis 



Lab 
Management 




Repsirihe 
Delect 



T 



Assign ktf Qifuction 
and Drs£ove:ry Phases 
antf Rod Catise 
C(}mplete Lab Text 
Template 



Final A^oi 
Cause 



Jusi Do Itf 

Small- Of Medium-Scale 

Improvement 

Implemeniaiions 



Fig. 10. Root-eatise analysis 
process. 



in the post -project root-cause analysis discussion. The eoti- 
tinuous process improvement cycle encourages exatnijialion 
of similar data throughout the development process. Take 
the HP division whose test data was shown as the lower- 
right pie chart in Fig. 4. It also capmreci data for specifica- 
tions, design, and code inspections. Ail this data is shown in 
Fig. 1 1. Some caution should be used m intorpretirig this 
specific data, since it was not uniTormly codec ted. For ex- 
ample, there may have been a higher percentaj^e of design 
work products than code work products, bui still less ihaji 
there w^as code tested. Nevertheless, this figure suggests 
some interesting questions and reveals possible insights. 

The bars above tbe centerline show counts for diJTerent de- 
fects that were found in tlie same phase in which they were 
created. Tall bars represent good opportunities to reduce 
these defect sources significantly. For example, the large 



number of module design defects suggests that a different 
design technjque might be needed to replace or compJement 
existing methods. 

The bars below the line show counts for defects found in 
phases after the ones in wliich they were created. The later 
defects are found, the more expensive they kW^ to fix. There- 
fore, the tall bars are sources of both belter prevention and 
earlier detection opportunities. For example, the require- 
ments, functionality, and fimctional description defects com- 
bine to suggest that designs may be chimging because of 
inadequate early product definition. It mighl be useful to use 
prototypes to reduce such changes. 

It is clear that this r>x"e of data can contribute to more 
informed management decisions. It also provides a way of 
evaluating the results of changes with better precision than 
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Software Failure Analysis Maturily Model 

Level 5: Opiimizing: Divisional goals sel to achieve compelilive 
advantage via specific software capatiilitjes. Peiiple given pfimery 
responsibilities that inc^lude process improvement through ronl- 
cause analyses. 

Level 4: Managed: Roet-cause analysis meelings are a regular part of 
development process. There may he people resfionsihle ier improve- 
ments. Mot all rout-ceuse analysis meetings result in aclion items, 
ftui management reviews data. 

Level 3: Defified: Defecl source informalion untformlv collectedn 
root-cause analysis meetings held, but not as a standard part of 
process. Data validating sybse^ueat improveinents is mostly 
anecdetaL 

Level 2: Emerging: Defect source inftinnation cnllectedr but net 
necessarily ueiformly and not necessarily validated. General 
agreement on what re quire me nts, design, and coding are. 



Level 1: Initial/Ad hoc: Defect source mformaiion not regularly 
collected. No recognized divisional defect source patterns. 
Incciin|ilete R&D process descriptioes. 
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Fig. 12* A flve-level software 
faiiure-HiiaJysiK niaLiiiity model. 



In tht* i>ast. The aitif>titit uf efforl reqiuretl fo sii>i1ain a con- 
llmions profess IrnprovtMiiPiH ryrle will vasy. rU^tn^ndiiig 
largely on ihe cost oj' iinpU'inenling I he ehiuiges suggesTeti 
by analyses. Which chaxij^es are chosen Tor itufjlenienlatiut^ 
will depend on other busiiu-ss aspects f>esities I lie pfojected 
costs and ben e fi i s . . 1 1 1 si n^ i n * * n ] I >e r I ha I 1 1 1 e c ost to siistai n 
fai hi re-aj^aly s is | > i at ■ t j < e m 1 1 < I 1 1 1 m i t^' si i n 1 1 ) i o venienis is sin all. 
and the returns have proven to far outweigh those costs,^ ''-''* 

Conclusion 

Process improvement projet'fs arc startef! in many ways, for 
many reasoris. In the soflwiirt^ tlekt espefiallyn processes are 
changing and aciapting daily, and software products and 
businesses are also rapidly evolving. One of the most effec- 
tive ways to both motivate aiid evaluate the success of net 
iniprovemerits is to look at flefect nends and patterns. This 
paper has shown how software defect data is a powerful 
management information source. I 'sing it effectively wiJl 
help achieve an optmial balance between reacting to defect 
mforniation and proactively taking steps toward preventing 
future defects. IIP di\isions have used .several succ^essful 
approaches to handling defect causal data, Tlie three root- 
cause ^malysis processes described ui this paper are posi- 
tioned against a suggested five-level maturity model shown 
in Fig. 12. 

Like many other best practices, failure analysis can be ap- 
pUed with increasing le\'eLs of maturity that lead to different 
possible paybacks. HP's experience says that the biggest 
benefits of diiving to higher maturity levels are: 

* Increased Ukeliliood of success when implementing proceas 
changes, pai'ticularly major ones 

* Accelerated spread of already-proven best practices 

* hicreased potential returns l>ecause necessar>^ ii^rtustniclure 
components are in place. 

Our successfuJ results from three failure-analjTsis approaches 
are very encouraging. Wtiile the time it takes to progress to 
higher maturity levels ^ill vary^ among groups, oiu experi- 
ence suggests that failure analysis starts providing remms 
almost immediately, particularly in visualizing progress. 

Ironically, the main Itmiter to failure-analysis succeas is that 
many managers still believe that they can quickly reduce 



total effort (ir schedules by 50 percent or more. As a result, 
they won't invest m more modesi [iroress ijiniroveiuents. 
Tills prevents them from gainirvg 50 [>ett ent improvements 
thrtnigli a series of smaller gains. Becatise it takes tune to get 
any improvement adopt etl orgaiii^sat ion- wide, these managers 
will continue to be disappointed. 

It lias nut l>een difficult to initiate use of tlie Fig. 3 defect 
model and tlie root -cause aiiLdysis (iroccss. The resulting 
data has led to effectiv^e, sometimes rapid, improvenients. 
There are few^ other available sources of infonnatiou timl ai e 
as useful in identifying key process weaknesses specific to 
an organization. This information will help to drive pi*ocess 
im|:>rovenien1 decisions and conunitment in an organization. 
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Evolutionary Fusion: A Customer- 
Oriented Incremental Life Cycle for 
Fusion 



Creating and maintaining a consistent set of specifications that result in 
software solutions that match customer's needs is always a challenge. 
A method is described that breaks the software life cycle into smaller 
chunks so that customer input is allowed throughout the process. 

by Todd Cotton 



Fusion pro\ides a thorough and consistent set of models for 
translating the specification of customer needs into a well- 
stnictm"ed software solution. For reasonably smuW projects, 
the sequential steps of Fusion map well into the sequential 
softw^are hfe cycle commonJy known as the waterfall life 
cycie. For larger projects, those representative of m*>st com- 
mercial and IT software projects today, an incremental life 
cycle siiclt jis Evolutionar>' Development pro\1des a much 
better SI nici lire for ti^maging ihe risks inhereiu in comtilex 
softwan^ cleveh>pmenL litis ijajjer introduces Evolutionary^ 
Fusion, the combuiation of Fusion, with its advantages pro- 
\ided by object orientation, and the key Evolutionary Devel- 
op meni concepts of eiyfy, frnjiient iteration, strong customer 
orit^ntation, and dynamic plans ajul processes. 

Although based on the best of other object Hiriented meth- 
ods. Fusion is a relatively new^ method. The Pension text^ 
was piiblished in October 1994, and as a member of the 
Hewlett-Packard sofhvare de%^elopment community, (he 
author \vas exposed to preliminary w^ork by Derek Coienitm 
antl his team eajher in lfl93. Tlie response fi'om the first few 
teatns lo at^t^ly Fusion to their work was extTemely encour- 
aging. As ruemt)ers of the Softwaie hiitiative, an internal 
consulting group focused on further extending Hewiett- 
[^ackard's software development competencies, the autlior 
and his colleagues have helped facilitate the rapid adoption 
of Fusion within Hewlett -Packart!. Fusion is now used in 
nejirly eveO'* part of Hewlett-Packard, coni rihuting to firod- 
nets and servi4'es as diverse a.s network jjrnloco] drivers, 
real-time mstniiiient llrmware, [u-inter drivers, internal infor- 
mation systems, imd even medical imaging and m^magement 
products. This iiaper is l>ased on these collected experiences. 

To simplify the presentation of concepts . tlie pai>er first dis- 
cusses ex pen prices gained workuig with suuill. collocaled 
deveUjpmerit teams. L;iter sections deal wilh the exlensions 
that have h^en rnatJe to scale Evolutionar> Fusion uj) for 
laiger teams split across geographic bomidaries. 

■ AdctfJtecl fram Ohji^t-Ortmited O&^sSopmnUf Wotk' fusm in ihe Hsai World. Ruth Malan, 
Reed Leisingej'. and Derek Coloman, Edptots, HEwletT- Packard Professional Books, Pubiished 
by Pmntice Hall PIR. Pnantica-Hall \m, 1996. ISBN n 13 ?43148-3 All rw^m \mm^,^ 



Need for an Alternative to the Waterfall Life Cycle 

The traditional waterfalJ life cycle Tor sofYwate development 
has sen^ed software developers well. By breaking software 
project.s up into se\ eral large seijuentiaj pha:ses — lypicaUy 
an investigation or definition phase, a design phase, an inv 
plementatlon phase, and a test [ihase — project te;uns could 
move forw'ard with confidence. System requirements were 
capturefl thioiigb significant customer interactiot^ dtiring tlie 
(iefinilion j)base. Once these requirements were complete, 
dve other [chases could progress witli ffx'us and elTiciency 
sine*' few if any changes to the specification would be 
allowed. With limited competition and with products that 
wottld remtun viable for yem-s, il was safe to assume that the 
system reqtiirentenls catitured many months or even years 
earlier wfHthi still be accurate. Unfortunately, this is no 
lotiger the environment in wliich software is developed. 

Today, our ability as softw^are enghteers and project managers 
to acx'onmtodate all risks and accurately schedule projects 
thai may int lude tens or even hundreds of engineers over 
several years of development is seriunsly challenged. Cus- 
tomers' needs, competitive products, aud even the develop- 
ment tools we use can change as often as evefy few months. 
We have at leas! two choices. We can tr>' lo ftirther refine 
our estimation and scheduJing skills, fixing more pjirameters 
of oiu' projects at very early stages of knowledge iiiid experi- 
ence, or we can look for an aitemati\'e cievelopment life cycle 
that better supt)orts the dynamic and eomplcK nature of our 
business today. 

One alternative to tlie waterfall life cycle is Barry Boehm's^ 
spiral life cycle. Actually mtire of a nwta life cycle, the spiral 
life cycle can be instantiated or "unwia|>ped" in a number of 
ways. One instantiation Is the iterative life cycle, an approach 
advocated by indusliyieaduig OO (object-oriented) metluKl- 
oltigists .such as.Iiui Runibauglr^ and tJrady ISdoch. ' An 
iterative life cycle replaces the munolidiit^ implemeniallon 
phase f»f die waterfidl life cycle with much smaller imple- 
mentation c:ycles (F^ig. 1 ) that start by building a very small 
piece of die overall funclionallty rjrtlu^ system and then add 
to this l)as4* over time until a cnmpletr system is lieliverecl. 
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Evolutianary Devatopment Life: Cycle 

Increments development "determines user needs and de- 
fines the system requirements, then performs the rest of the 
deveiopment in a sequence of builds/^ 

Another instantiation of the spiral life cycle is Evolutionary 
Development, projjosed by Tom Gilb.** Evolutionary Devel- 
opment adds to tJie iterative life cycle a much stronger cus- 
tomer orientation that is implemented through an explicit 
customer feedback loop, Evolutionaiy Development "differs 
from the incremental strategy iti acknowledging that the 
user need is not hilly imderstood and all requirements can- 
not be defined up front ... user needs and system require- 
meriLs are partially defined up front, tiien are refined in each 
succeeding build. "■■ Tlie Evolutionary Development life cycle 
has been used successfiilly within Hewlett-Packard since 
1985 and was the natural choice to combine with FiLsion 
when we needed an alternative to the waterfall life cycle. 

Evolutionary Development 

Evolutionary Development (EVO) is a software development 
methoti and tife cycle that i epiaces traditionaJ waterfall 
development with sniallj increnvental product releases or 
huildSt frequent delivei>' of tlie product to users for feedback, 
and dynamic planning that can be modified in response to 
this feedback. As originally |>resented by Tom Gilb, the 
method had the following key attributes: 

1. Muitiobjective'driven 

2. Early frequent iteration 

3. Complete analysis, design, build * and test in each step 

4. User orientation 

5. Systems approach, not merely aJgorithin orientation 

6. Open-ended basic systems architecture 

7. Result orientation, not software development process 
orientation* 

Using EVO, a product development tean^ divides the project 
into small chunks. Ideally, each chimk is less than ^% of the 
overall effort. The chunks are tlien orciered so that the most 
useful and easiest featmes are unplemented first and some 
useful subset of the overall product can be deUvered every 
one to four weeks. Within each E\T> cycle, tlie software is 



Fig. L Different models of the 
SI jftware development life cycle, 

designed, coded, tested, and then delivered to users. The 
users give feedback on the product and the teant responds, 
often by changing the product, pltuis, or process. These 
cycles continue mitil the product is shipped. 

EVO is thus characterized by early and frequent iteradon^ 
starting with an initial implementation and followed by fre- 
quent cycles that are short ui diuration and small in content. 
Drawing on ongoing user feedback, planning, design ^ cocUng, 
and testing are completed for each cycle, and each release 
or build meets a miiiimimi quality staitdard- This metiiod 
offers opportimities to optiintKe results by modifying the 
plan, product, or process at each cycle. Tlie basic product 
concept or vakie proposition, however^ does not change. 

At Hewlett-Packard, we have found that it is possible to 
relax some of Gilb's ideas regarding EVO.^" hi particular, it 
is not absolutely necessary to deliver the product to real 
customers with customer-ready documentadon, training, 
support, atid so on, to beneilt from EVO- For instance, cus- 
tomers pailiciparing in the feedback loop change dming the 
develoimient process. Results from the early cycles of devel- 
opment are tyt:)ically given to other team members or otlier 
project teams for feedback. Less sensitive to the lack of 
complete doctmientation and training materials, they can 
still give valuable feedback. Results from the next several 
cycles are shared mth surrogate customers represetued by 
members of the broader Hewlett-Packard community. The 
goal is still to get the product into tJte hands of actual cus- 
tomers as early as possible. 

There are two other variations to Tom Gilb's guidehnes that 
we hai^e found useful within Hewlett-Packard. First, the 
guidehnc that each cycle represerU less than 5% of the over- 
all implementation effort, h^is translated uito cycle lengtlis of 
one to four weeks, with two weeks being the most common. 
Second^ ordering the content of the cycles is used within 
Hewlett-Packard as a key risk-management opporlimity. 
Instead of imjilenienting the most itseful and easiest features 
fii^t, many development teams choose to implement in an 
order that gives the earliest insight into key areas of risk for 

' See s\%o th€ article m pagi 3S. 
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^\Tiat is Fusion? 



Fusmn is a systematic software development method for otjject-oriented 
software develDpment, Developed at Hewlett-Packard laborataties in 
Bristol. Ef^glajKi, the metk)d integrates and extends the best featuies of 
earlier Qtjjtctorigmed methods, Fusion is a fuIf-cGverage method, provid- 
tn§ a direct route from a requtmmsnis definttion througfi amtysis and 
design tc a pragrsmmtn^ language implementation 

What Fusion Offei^ 

• 1 1 provides a process for software development. It divides this process 
into phases and says what should be done in each phase It gives guid- 
ance on the order in which things should be done within phases so that 
the developer knows how to make progress, ft provides criteria that tell 
the developer when to move on to the next phase. 

• It provides a comprehensive, simpJe. weli'delmed notation for all of its 
models, Because this notation is based on existing pmctices. it is easy to 
learn. 

• It provides management tools for software development. The outputs of 
the ditferEnt phases are clearly identified, and there are cross-checks to 
ensure consistency within and between phases. Each phase has its own 
techniques and addresses different aspects of translating s requirements 
document into executable code. 

■ It is adaptable, A lightweight version can be used in projects that cannot 
afford the effort required to use the full version, or parts of the process 
or notation can be used within other development processes to address 
their weak points. 

The Process 

The Fusion method structures the development process into analysis, 
design, and rmpfementaiion phases [see Fig. 1 1. 

Analysis 

During the analysis phase the analyst defines the intended behavior of 
the system. Models of the system are produced, which describe; 

• The classes of objects that exist in the system 

• The relationships betwean those classes 

• The operations that can be performed on the system 

• The allowable sequences of those operations. 

Design 

The designer chooses how the system operations are to be implemented 

by the njn-time behavior of interacting objects. Different ways of breaking 
an operation into interactions can be tried, During this process, operations 
are attached to classes. The designer also chooses how objects refer to 
each other and what the appropriate jnheritance relationships are 
between classes. 

The design phase delivers models that show: 

• How operatioos on the system are implemented by interacting objects 

• How classes refer one to another and how they are related by 
inheritance 

• The attributes of and operations on classes. 

Designers may need to investigate the substructure of some classes and 

their operations in more detail. They do so by applying the analysis and 
design techniques to those classes, regarding them as a subsystem. 
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Rg. 1 The fusion pmeess 



Implementation 

The implementer must turn the design into code in a particular program- 
ming language. Fusion gives guidance on how this is done \n the followmg 
ways: 

• Inheritance, reference, and class attributes are implemented in 
programming-lanquage classes. 

• Object interactions are encoded as methods belonging to a selected 
class. 

• The permitted sequences of operations are recognized by stale 
machines. 

Fusion also maintains a data dictionary, a place where the different 
entities of the system can be named and described. The data dictionarv 
is referenced throughout the development process. 

In summary, Fusion is a complete, yet lightweight development method 
that can be tailored to meet the different needs of software projects. 

Derek Coleman 

Professor of Computer Science 

University of London 
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the project, such as performance, ease of use, or managing 
dependencies with other teanis, 

Benefits of EVO 

The teani_s within Ilewlt^tt-Parkard that have adopted Evolu- 
tionary Develojinienl a.s a projpet life ryrle have done so 
Willi explicit henefiti^ hi mind, hi addition to better meeting 
customer needs or hitting market windows, there have been 
a number of unexpected benefits, such as increased pro- 
ductivity and reduced risk, even the risks associated with 
changing the devekjpment process. 

Batter Match to Customer Need and Market Requirements. The 
explicit customer feedback loop of EvoiutionaO' Develop- 
ment results in the deliver>^ of products that better meet the 
customers' need. The waterfall life cycle provides an inves- 
tigalion or definition phase for ehciting customer needs 
tl^rougb ffH^tis groups and storyboards, but it does not pro- 
vide a mechanism for continual valiflation and refmemenl of 
customer needs throughout the long implementarion phase. 
Many customers find it difficult to aiticutate the full range of 
what they want from a ]Droduct imtil they have actuaUy used 
the product. Theii' needs and exjDectations evolve ss they 
gain experience with tJie product. Evolutionary Development 
addiesscs this by incorfi orating customer feetit>ack early 
and often during the implementation phase. The small im- 
plcnu^ntation cycles allow the developinent I earn to respond 
to cusl omer feedback by nmciifying the plans for future im- 
plementation cycles. Existing functionality can be changed, 
while planned functionality can be redefined. 

One Hewlett-Packard project used a variation of EvfiUitiomuy 
Developmeni that also included an evolutionary' approach to 
produel denuilioii.^ Duhug the first month, the development 
team worked from static visual designs to code a protot>T^e. 
In focus group meetings^ the team discussed users' needs 
and the potential features of tiie product and then demon- 
stiated their' ]lrotot>^le. Tlie focus groups expressed strong 
support fo}' the [>roduct cone ept, so the project proceeded to 
a second phase of focus group testing incori:>orating the 
feedback from the first phase. Once the feedback from the 
second round of fot us groniis was incoq) orated, the feature 
set was established and I he juodnct definition completed. 

Implementation consisted of four-to-six- week cycles, with 
software delivered to customers for use at the etid of each 
cycle. The entire developmeni effori spanned ten monUis 
from defmition to produel release. The result was a world- 
class product that has won maixy awards and has been easy 
to support . 
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Hitting IVIarket Windows. To enlimice productivity, many large 
software projects divide their tasks into independent sub- 
sets that can be developed in parallel. VViib few dependen- 
cies between subteanis, each team can progress at its own 
pace. The risk in this approach is the signillcant effort that 
must be invested to bring all the work of these subl earns 
together for final integration and system test. When issues 
are micovcred at tlus late stage of development, tew options 
are available to tiie tlevelopnient team. It is diffit nit if not 
impossible to pnuie functionality in a low-risk maimer when 
market windows, technology, or competition change. The 
only option open to the team is to continue on, finding and 
removing defects as quickly and as efficiently as possible 
(see Hg. 2), 

With an EVO approach, the team has greater flexibility as 
the nitirket wuKiow approaches. Two attributes of EVO con- 
tribute to this flexibility, Rrst, the sequencuig of fimctionality 
diiring the imi)leiiientation phase is sucli diat "must have" 
features are completed as early as possible, wliiie the "high 
wa:rl " features aie delayed mi til the later EVO cycles. 
Second, smce each cycle of the implement at ion phase is 
expected to generate a "complete** release, much of the inte- 
gration testuig has already been com]^leied. Any of the last 
several EVO cycles can become release cmididates after a 
final roinid of integration and system test. Wlien an eai'lier- 
ihan-plaiined release is needed, the last one or two EVO 
cycles ( an be skipped as long as a viable product already 
exists. If a limited nnmber of key features me still needed, 
an additional EVO cycle or two caii be defined and imple- 
mented as iUustrated in Fig, 3. 

Engineer Motivation and Productivity. Some of the gains in 
produttivity seen Ijv project teams using EVO have been 
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atuibuted to higfier engineer moD\ aticm. The long iniple- 
nientalion phase of the waterfall Me cycle is often charar- 
lertsed by lai^e variations in engineer mottiation. It is difn- 
cult for engineers to maintain peak productivity when it may 
be months belore they can integrate their work Vkilh that of 
others to see real r^tilts. Engineer motivation can lake an 
even greater hit when the t>Tanny of the reiea^se date pn> 
hibits all but the most trivial responses to customer feedbacit 
receh e<l during the final stages of system test 

EVO has led to higher producti\ity for de%'elopmoni teams 
by maititaining a higher level of motivation throughout the 
implementation phase. The short implementation tycles 
keep eveiyone focused on a small set of features and tasks* 
The explicit customer feedback loop and the mnall imple- 
mentation cycles also allow the development team more 
opportmut^' to responti lo ctLsf omer feedback and thereby 
deliver a |>roduct Lhal they know represents their best work. 

Quality Control Although software development is in many 
ways a nuttiufat luring process, sofhvare de\Tlojjmen! teams 
have struggled to apply quahty Lmprovemenl processes such 
as Total Quality Control (TQC). l^nlike the manufacturing 
organizations Hiat can measure aritl reOne processes with 
cycle times of hours, minutes, and even seeorKis, the water- 
fall life cycle gave cycle times of monliis or years before the 
software de\ elopment process rei>eatefl With EVO, the soft- 
ware implementation cycle is dramatically reduced and re- 
peated multiple times for each project. All parameters of the 
miplementation process are now available for review and 
imprcjvement. The impact of changes m processes and tools 
am be me^isured arifi refined throughout the implementatiort 
phuse. 

Reducing Risk when Clianging the Development Process. Many 
tt*;ynsexpenence considerable anxiety as litey make tlie 
tmnsitifjn to an object-orienled approaclt lo cievelopment. 
The transition to OO tisually entails a number of changes in 
the way a software engineer works. There are new analysis 
and design models to af)j}ly, new nolalions to master, and 
new, occasionally eccentric, tools and cotnpilers hy learn. 
There is also valid t*oncein about adopt Lug a new method at 
the begimung of the development process. Few t^ams are 
willing to make a full commitment to a tww method when 
they have little exj>erience wilh if. There may even be orga- 
niisational chtmges anticipated il' Ihe organ i/alion is looking 
for large-scale productivity gains through formal izeil reuse. 

Development teams and managers waiti sotne way to man- 
age lite risks associated wilh making so many simultaneous 
(*hanges to their cievelopment environment. EVO can help 
manage tiie risks. The repeating cycles during the inipletnen- 
tation phase provide for continual review atid refinpment of 
each pammetcr of the development environment. Any asjiecl 
of the development environment can be di"opped, modified, 
or strengiliened to provide tlie maximum benefit to the team. 

Costs of EVO 

Adfjpting Evolutionary Development is tiot without cosIh Ii 
presents a new ijarafligm Uw the proje<i manager to follow 
when flecomposing juui |)kuuiing the project , and it rt^quires 
more explicit, organized decision making than many manag- 
ers and teams are accustomed to. 



In traditional pnijerts, suijsystems or code modules are 

idenrified and then parceled out for implementation. As a 
result, planning and slaXfrng of large projects were driven by 
the siTucttire of the system and not by its m tended use. In 
contrast. Evolutionary^ Jlev^elopment focuses on the intended 
use of the system. The fundi on ality to be deliv^ered in a 
given cycle is determined fiii>t. It is common practice to im- 
plement only those portions of subsj'stems or modules thai 
suppori tiiat functionality during that cycle. This approach 
to buikhng a work breakdown structure presents a new par- 
adigm to the project manager and the development team. 
Subsystem and modnle completion cannot be itsed for inter- 
mediate milestone definition because their full funclionaliry 
is not in place imtil the end of the project. The time needed 
to adopt this new p^u-adigm and create an initial plan can be 
a ntajor barrier for some project teams. 

Many development teams lack a well-defined, efficient 
decision-making proceas. Often rliey make decisions im- 
plicitly within a limited context, risking the compromise of 
the broader project goals and slowing progress dramatically 
Evolutionat^' Development forces many decisions \o be 
nuidc expticJI ly in an organized way because feedlmck on 
the product is received regularly and schedules must be 
til J dated for each implementation cycle. 

The continual stream of information that the project team 
receiv^es must be tnmslaled into three categories of tlecisions: 
changes to the prodiKi as it is cunently implement efi. 
changes lo the plan that will fun her the product imptenien- 
tation^ and changes to the development process used to de- 
veiojj the product. Fortimately, because of EVO's shoil cycle 
time, teams have many opportunities to assess the restilts of 
decisions and aciiust accordingly 

Evolutionary Fusion 

F'lisitm iuid Evolutionary Developnumt are complementary. 
One of the primary assumptions of EVO is that one can 
decompose the functionality of a project into small manage- 
able <iuinks. It is also expet^ted that these chunks will irro- 
vide soEue measttrable value to the ititcnded user mid cjm 
thus be given to the user for feedback. Ftjsion provides the 
methoti of decomposition. At the highest level. Fusion 
decfunposes the functionality (jf a systenv inio use scenarios* 
Use scenarios atv defuu^il front the perspective of a user or 
agent of the system and are expected tcj capture a use of the 
system that provides some value to the agent . 

EVO also presupposes that an architecture capable of 
accomuKKlating all the exiwcletl fitrKtionality of the system 
r at 1 h e ( k' ti n et 1 1 j rit j r t o i ni p le me 1 1 tat i o n . Th is arc hitectiire 
musi be flexible enongli to accomniodaie new or redefined 
functionality resulting from customer feedback Fusion helps 
<Teale this flexible architecture. The object model provides 
an archil ect lire that encapsulates conmu>n functionalily into 
cliisses and proiides flexihility anri extcnsiinhty through 
generalization imd specialization. Fusion also accoimnodates 
large-scale change through the well-tleflrvfHl linkages between 
nindels, Ifnct essary, char\ges to fiuuiionalily nm be rolled 
all Ihe way up tr> (he use see nonius anti then i itscaded hack 
down thrt>ugh the appropriate analysis and design models. 
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replacing guesswork in assessing the impact of a change 
with a more systematic approach. 

Evolutionary Fusion di\ides a project into two m^or phases: 
tiie definition phase and tlie development phase (Fig. 4). 
During the defmition pluise, a project's functionality is speci- 
fied and it^ viability as a product or system is first estimated 
The F\iSJon analysis models play a key role in this phase. 
TJie use scenarios serve to remodel the specification docu- 
ment, checking it for clarity and completeness. They can 
also be reviewed with customers to vahdate tile development 
team's understanding of customer needs. The objecl model 
captures the initial architectiu-e for the system ^k1 provides 
additional checks of the specific a ti on. The data dictionaiy 
captures the team's emerging common vocabulary and 
understanding of the problem domain. The operation ntodel, 
through its system operation descriptjons, gives an indication 
of the size and complexity of tJie project. This ijiformation is 
critical for estimating resomce needs and developing the 
initial plan for the development phase. 

The second phase is the development phase, in which code 
IS incrementally designed, implemented, and tested to meet, 
the specification. Each development cycle follows I lie same 
pattern. Mrst, the analysis models are reviewed hjr com- 
pleteness with respect to the funct lonality to be imple- 
mented during that cycle. Next, the Fusion design models 
are created or updated to support die functionality And 
fin ally, the code is wiitten and regression tests executed 
against the code. In parallel v^ith the development activities 
of the team, selected users or customers of the system are 
working with and providing feedback on the release from 
the previous cycle. This feedback is used to atijusi the phm 



for the following cycles. To complete the development 
phase, a final round of integration and system testing is 
done. The next two sections discuss these two phases in 
more detail. 

Definition Phase 

The deOnilion phase is best characterized as a period tjf 
significant communication and thought. Conmnmication 
must occur between all members of the project team to 
ntake sure that everyone shares a conmion understanding of 
the projects goals. Thought miisf be put into the specification 
document lo make sure that it is coniplete and unambiguous 
and that it meets the requirements. Conmmniration must 
occur betw een the de%^elopment team and the intended users 
of the system to ensure tiiat the sy.stem. at least as it can be 
specified on paper during this early stage of the project , will 
meet their needs. Thought must go into definuig an architec- 
ture capable of supporting the mtended fimctionEdity of the 
full system. The goal is ro identify and resolve as many issues 
as possibi€^ during this phase. Specification errors that are 
not resolved during this phase can be extremely costly lo 
repair later 

Oiu- experience has shown tliat the Fusion analysis models 
are ideal for stluuilating the thought and supportuig the 
communication that must occur during Uie definition phase. 

Analysis Models — First Pass 

Like Pusiont Evolutionary Fusion requires some form of 
system specifical ion as a starling point, and just about any 
level of detail in the system specification will do. When the 
specification is at a high level, the analysis models serve to 
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identifj' large numbefs of issu^ and questioris thai need to 

be resohed before dev^elopment can begiii. WTien the speci- 
fication is at a more detailed level, the analysis models ser%^e 
to remodel and recapture high-le^Tel stnictiire and function- 
aHt>^ thai may be lost in the detail. We have yet to define what 
level of detail in the system specificalion yields the most 
eJTtcieni definition phase for Evolutionary Fusion. Regard- 
less of the le^el of specifiration detail* the anajysis models 
pro\ide the beginning of a comnton %'ocabulary and under- 
standing of the problem domain that will serve the team well 
througliout the project. 

The most critical component of the system specification is 

the t-alue pt-ofmsition,^ The value proposition clearly articu- 
lates why the intended customer of d^ie system v\ill choose 
to itse it o\^er the other options available. The ftmclionaUty 
defined in the specification is the development team s initial 
best estimate as to how to deliver that value proposition. 
Tl\ere are usuaOy cotmtless other ways to deliver it. The 
explicit customer feedback loop of Evolutionary'' Piusion will 
validate the best estimate over time and vn^ suggest better 
ways to deliver the value proposition. The value proposition 
itself sliould remain constant tliroughout the entire develop- 
ment process. If the vahie proposition changes during tJie 
development phase, il will be qiute difficult for the team to 
make all the modifications necessary to implement a new 
one ajid still end up with a coherent set of product features. 

Use Scenarios 

The Jlrsi atialysis model to be created is the set of use 
scenarios* To provide some structure for this acrivity, it is 
useful to first generate a hst of aO the agents that exist in the 
system *s enviroiirnent. It can often be a challenge to decide 
what constitules an agent. For example, the file system pro- 
xdded by the operating sysiem is clearly part of any system's 
en\1ronmenl. It cmi be expected to provide services to aJitl 
make demmvds an tlie system beiiij^ defined. Ret^resenting iJie 
f\le system as an agent does not adtl any additional clarity to 
the team*s tmderstai\ding of the system under definition. 
However, represent ing specific files as agents, stich as con- 
figuration files, legacy databases, or data input files, does 
add clarity In one project , it was useful lo model, as an 
agent , a criUcaJ data input file generated externally to the 
system. A general nile of thmub is that an agent must add to 
thp understanding of tlie system tf it is to be included at tliis 
early stage. 

Once the list of agents is complete, each agent can be exam- 
ined with respect to the demands it will make on the system. 
Tliese demands are cajit tired as use scenarios. As with de- 
fining agents, determining an appro] jriate level of granular- 
ily for the use sceuiirios can be a cliallenge. Another rule of 
tliuinb Is that use scenarios shoukl provide complete chunks 
of value from the perspective of the agent, in the project 
mentioTwd above, the system was modeled as pro\ddtng 
value to tli<^ input file by ai^cepting records of data ti om the 
file and translaiing tliose records Into a format I hat could hv 
used by the rest of Uie system. Tliis approacii will help avoid 
the issue of trying to keep all use scenarios at the same level 
of grantilarity. It is the agent tiiat defines the appropriate 
level of granukuiiy, not tlie system as a wiiole. 

Once the use scenarios have been specified, each is tlia- 
grannned tt> decompose it further inio discrete system 
operations and evenLs, It is also ust^ful to annotate in the 
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Fig. 5. U^e scenaiiD with time-eonstramt annotation. 

margins of the use scenario diagram any time coiistraints 
that may exist (see Fig. 5j. For systems of reasonable size, 
it is difficult to define a correct set of use scenarios on the 
first try. Bttilding tiie use scenarios is itself an iterative pro- 
cess of refinemenL 

Object Model 

As Quid-* states in his text on software engineering strategies, 

"The success of the Incremental dehveiy approach rests 
on the ability of the designer to create — from the start — 
an architecture that can support the ftdl ftmctionality of 
the system so that there is not a point during the sequence 
of deliveries %vhere the addition of the next increment of 
functionality rettnires a massive re-engineering of the 
system at the architectural level (p. 59)." 

The Fusion object model, the next analysis model to be 
createti, serves as that architecture. 

Once tlie use scenarios are complete, the development team 
has a much clearer understattding of the demands that will 
be placed on the system. Tlie use scenarios are ati excellent 
source of information for building the olyecl. model. The use 
scenario diagrams cati be stepped through, making sure ttiat 
analysis classes exist to support the need of each system 
operation. It is also quite common that building the object 
model will generate fiiriiier refinements ai\d improvements 
to the use sceuaritjs. 

Operatioii Model 

The last analysis model to be created during tlie definition 
phase is the operafion model. It docimients in a declarative 
fashion the chEinge in the state of the system as it resfjonds 
to a system operation. Each system operation is described 
using only terms from the use scenarios, object model, und 
data dictionary. 

A complete specification of the system exists when the 
operation itiodei is completed. The tise scenarios capture 
the intended uses of tJie system froiti the agents' poitit of 
view. The object model captures the high-level architecture 
of the syst eu). The operation model dctcuments the effect 
that each system operation luis on (he systetn. The creation 
(jf each model has stiuui luted Hit: dKniglit necessary to iden- 
tify and res(jlve issues, while the notation for each model 
establishes a cotnmon <'omnmnication formal for the team. 

Managing the Analysis Process 

An aiiprTjpriate qtiesfioti to ask at this pt>int is how much 
linu^ should be invested iit making a first pass at the imalysis 
models. Although tiitTe is no fornnila that we can oiler tor 
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Evolutionary Fusion, the application of a progresis measure- 
ment tec^hniqnt* used by majiy devplopnient teams during 
imjiieinentation works surprisingly well at this early stage t>f 
development. During the integration ;iiid system test pliase. 
mariy teams compare liie rale at whirh delects iire behig 
identified to tlie tale ai whi(^h defeet.s are beirtg isolated aivfl 
repaiied. In tJie early pari of ilns please, the rate of delect 
i dentin ealion exceeds the raU^ of tlefecl repair. At some 
later point in this phase, the rate of repaii' exceeds tJie rate 
of identification, and estimates can be made on when the 
desired defect density will be reached and the product can 
be released. 

A skrular approacli can be iise<l to tr'ack pn>gress during the 
creation of the jyuilysis moileis in KvoUjtioJiary Fusion's 
definition phase. Any issue identified during the creation of 
the analysis models can be considered upotetUial defect in 
du^ sj^jecificaiion of the system. As wUlr testing code, the 
initial attempts bj build the analysis models will generate a 
laigc number of (KJtential issues, or defects. .As the creation 
of tile analysis models progresses, fewer and fewer issues, 
or detects, will lie fomid. Once the rate of resolving, or re- 
pairing, these issues exceeds the rate of finding new issties, 
a comjjietion date for tlie tlrst pass at the analysis models 
can be estimated. 

An additional parameter often assignetl to defects is a classi- 
fication that represents tlie severity of the defect. Few sys- 
tems are sliipijed witli knowji defects that can cause mire- 
coverable tiala loss, but many arc shipped with known 
defects that ha\e only limited impact on Ihe systems use. It 
can be helphil to ai^ply a simllai* c las.si Ileal ioJi schejue to the 
issues fomid during iuuilysis J ^^ Matiy issues identified will be 
of such im|iart tluit they must he res(j]ve(i before moving on 
to the developmejil phase. ( Jther issues will he of lesser 
impact and^ as such, resolution can be delayed until the 
development phase. Tliere is also a third class of issues that 
relates directly to design or implementation, lliese must be 
ret Uissificfl as tlesign or implementation issues and marked 
kit resoUihon during that phase, 

llu^re is m\ expectation that a team must complete all the 
aimlysis phase models before moving on to implementation. 
Our experience tuis shown that this is not die case. It is only 
necessary to complete a higleievel view of the complete 
system aiul to resolve I he cd! ieal lUKi serious "defects" that 
have been Itjgged against tin- analysis models. This aiir)roaeh 
can also help teams avoid "an^ilysis |>ai'alysis/" the malady 
that afflicts many teams %\hen they tr>' to resolve every 
knowii issue before mo\1ng on \o design and implementation. 
The an^dysis models will be remitetl as the first step of each 
implementation cycle, so fiuther additior^s mid refjuemenls 
can be made tiien. 

It is cUfficult to aecinately estimate the length of the analysis 
phase, especially if if is the team's first use of object tech- 
nology. Fortimalely, using the apprtjach desirilied here can 
pro\1de early indication of progress so that resources can be 
maiiagetl accordingly. 

Building tlie Plaii 

The last tiisk of the Evohitionary Fusion definition phase is 
to phui the next phiise, development. This task consists of 
three major steps: assigning o^^Tiei'sIiip for the key roles that 



must be played during this j)hi4se, defining tlie standard EVO 
eyerie, and detenninhig the sequence in which fimctionality 
will he developed.^ ^ 

Kev Roles. For the development phase to progress in a smooth 
and efficient maiin(*r it is !ielpful to dt>tuie and assign <jwiier- 
shi|,> for tlirce key roles: project majiager, teclmical lead, and 
user liaison. On large project teams, these roles may be 
shared by more than one person. On smaller project teams, 
a i)erson may t>lay nune than one role. 

Project manager Many aspects of the project manager's role 
bcHoine t*ven more critical with Evolution an IKHclopment, 
The project mmiager must wurk with the marketing team 
and the customers to establish the projeet^s value proposi- 
tion, identify key project risks, document all couimitments 
and dependencies, and ariiculate how Evolutitjnary Deveh 
opment will contribute to the projecl's suec*ess- Agreement 
on the vtilue proposition is critical, as it will help keep the 
decision-making process focused. The key projecl risks will 
be used to sequence the implementation so that tliesc risks 
can be char act eilzed and addressed as early as possible. The 
conuuitiiients and dependencies will also be a key consider- 
ation when sequencing the implementation cycles. It is also 
imt>oi1ant that the jjrojet t manager solicit uikI address miy 
concerns that the project team lias with the Evolutionary 
Development approach. 

live project manager must also define and manage die deci- 
sion-making process. AJthougli this is often an imt)licit task 
of the project manager, the large amount of information and 
the increased numi)er of decisions thai unist be uiade using 
Evolutional^ Fusion rec]iure that this pn^cess be made ex- 
phc.it, Biised on the kuids of chmiges anticipated durhig the 
project, the project manager must consider how information 
Will be gathered, how decisions will be made, and how^ deci- 
sions will be comnumicated. With very shoil; development 
cycles, delayed decisions can slow progress dramatically. 

Working with the tecluiical lead, the project manager may 
also decide to include explicit design cycles in the schedule. 
For software architectures and designs that are expected to 
sur\ive many years, suppcjriing nmhiple releases or even 
nuiltiple product lines, il is impoilant to invest in the evolu- 
tion of the arch it eel ure. As the devekjpment phase pro- 
gresses, cetlain isolated deeisituis that compromise some 
aspect of the iircliitecture will be made. There will also l>e 
new^ insights into the architecture and its robustness that 
could not have l^een anticipated during the deb nit if ju phase. 
Design cycles dedicated to die architecture will dehver ikj 
new fimctionality for tiie user. By uu'luding tasks such iis 
aichitecture refhiement, design develoj>ment, and rlesign 
mspections, these cyeJes will dehver to future EV( ) cycles 
an arclutecture that is better equip]ied to meet the deniands 
that will be plaeeti on it, 

Tecluiical lead: Tlie tecluiical lead is responsible for manag- 
ing the iircliitectm'e of the project as well as tracking and 
helpuig to resolve technical issues and dependencies thai 
arise between engineer's and betw^een subsystems. The tech- 
nical lead also plays a key part m defining the detailed task 
plans for each implementation cycle. With a broad \iew of 
the system, die technical lead can make sure that tasks 
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scliediilecl for an implementation cyrle aie feasibie ami that 
they all contribute to the stated delivei-ahle for the cycle. 

User liaison: The user liaison manage the team's interaction 
with the iLser^, ineluciiiig selling iipl he user feedback pro- 
cess by tiefmiug exjjertalioiis ot Ihe iisei^, locating and qual- 
ifying users against these exjjectatioas, aiul coordinating 
any initial training that the users will need on the systetu. 
Once the development phase Is undenvay, Ihe user liaison 
will be responsible lor coUectiiii^ feedback, tracking user 
l)articipation tmd satisfaction with the pnj<:ess» aiiti ensunng 
thai users are kept mTormed of the development team's re- 
sponse to theu- feedback. 

It is inipoitant to keep in mind that the usei^ t>rt)vidinj^ feed- 
back on the system rtiay chatige over lirtie> In die t^arly de- 
velopment [)ha.se. it may be unrealistic lo deliver the jsysiem 
to actual users, since there may sittiply nut l>e euougli rtuic- 
ttonahty in the system. For these releases, other members of 
the project leam or other members of the org<mii!:aiion can 
act as smrogates for actufd users. 

Oefintng the Standard EVO Cycle, The next step iit planning the 
flcveUjpinejil phase is fo define Ihe stiuidiird EVO cycle lo 
be used. This lask uicludos establishmg the length of the 
cyde as well as the milestones within the cycle. The general 
rule of thutni> is to keep the cycle length as short as possible. 
Within ilewlett'Pat kardt projects have used a cycle length 
as short as une week and ;is kjng iih four weeks, Tfie typical 
cyc:le time is tW'O weeks (see Fig. 6). llie prinuuy factor in 
detenninittg the cycle length is how often management 
w^ants insight into the project s progress and how often tht*y 
want the opportunity tf> a(|jusi the project [jlaii, prr>ducl, and 
process. Since it is tuore likely that a tean^ will lengtlien 
their cycle time than shorten it, ii is best to stiirt with im 
short a cycle as possible. 

Grouping atitl Prioritizing Functionality. With key roles assigned 
and the stamlard cycle delined, the hist step in phmning tlie 
develoj>iiietit pliase is to grtjup :uk1 ptioritize the fiuictioiuility 
iiitii iniplementatioti chunks. Tlie chiaiksmust be no iarger 



Fig. 6. Sample two-week EVO 



thati can be dellveretl m the standard cycle time. Prioritiza- 
t it^n ensures thai critical or high-risk features me compleieci 
early and that low-rLsk features are deli\ ered last. Some of 
the most common criteria used for grouping and prioritizing 
ftmctionality will be discussed later in this section. 

The deliverable from the platining phase is an implenTenta- 
tion schedule that maps all funcrionality for the system into 
imijlenientation cycles and jjtovlfles enough detiiil for the 
first three or four t^ycles so that actual in\plementation can 
begin. To hcl]j ci eve lop this schedtde iuid to niaintctin a user 
perspective, the Fusion use scenarios and system operations 
pro\1de a useful grouping of system functionahty. System 
ot>erathms, which may appemin multiple use scenarios, are 
grouped togeUier to define use scenarios, 

11 le llrsf step is to divide the systiHii devdt)iunent Inlo fotir 
or fjve niajoi chunks and lo gjoup lliose use st en^uitjs that 
include toj>-priority fmictionality itito the first <'hunk (Hg. 7), 
The rest of t.fie use scenarios cmi then l>e grouped into the 
rollowing m<\j or chunks, with ibe use scenarios containing 
tlie lowest priority funt lionality in the last chiuik. At this 
stage tvH*h chunk sbt>uld coniain a|>|;>roximately tlie same 
numl>er t^f use scen;yu>s. 

Tlie next step Is to order the use scenarios within tlie first 
chmdf Lismg the same criteria as before ( Fig, 81 When pro- 
ducing this ordering, it is not uncommon to niuve sceiuuios 
hetw't^en gioups to achieve a bettet^ I valance* atid setjuetice. 
Suice system nperations may ap|>ear in multiple use st^enar- 
ios, mimy of the system operations that are contained in the 
use scenaiios of later groupings will be imivh-^rnenled with 
use sc:enarios In earlier groupings. Therefore, it is best lo 
have the fewest tise st^enarios in the first chunk and the 
most in the last chunk. 

The .system operations front the use scetiarios in \lw llrsi 
group can now be grouped and seciuenced inlo the firsi few 
iitiplementation cycles (Fig. H), Ke(*t> in niind titat llie (hdiv- 
eia Ivies from ear'h cycle should be defitietl in such a way tliai 
tliey CcUL \h' v^ilidated by a user of the systetn. For these t^iirly 
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cycles, thf limited fmictionalit^'^ may he best validated by 
anotiier member of the development teani. The key concept 
is that you must be able to validate tJie success of the cycle 
in some way. 

When est.iniaf ing the number of system operations thai the 
development team t:m\ inii>lentenl in a cycle, experience has 
shown thar taking the comn^on wisdom of the team and 
dividing Utat number in luUr yields the best results. Because 
this approach to develoiimenl niay be new to the team, it is 
extremely importatit from a ntotivaUonaJ perspective that 
these first few imfilemenliition cycles be successful Also^ 
keep in mind thai there Ls a fair amoiml of iurriistnulure 
developed and put in place during these first few iniplemeiv 
tation cycles as welL The tools ai\d the proc^ess will undergo 
significant refoiement during these firs! few cycles. For 
these reasons, keep the functionality content t)t the tirst, few^ 
implementation cycles to a minimimt, 

A technique used widely within Hewlett-Packard is to adopt 
a naming scheme for the impteiuentat ion cycles. One team 
used tlie names of wineries from their local Northern Call' 
foniia region. As they completed each cycle, tlieir project 
manager would l>uy a bottle of w^ine from that wuiery^ and 
store it away. Once several cycles were completed, the team 
w^ould celebrate by taking the wine to a fine restaiu'ant for 
lunch. 



The tinaJ step is to estimate the number of cycles needed for 
the rest of the mtended furtcliouidily and to projecf a final 
implementation completion date (Hg. 10). Tills is accom- 
plished by counting the new system operations that nnist be 
iruplemented m the rest of the chiuiks and tiiviiling hy the 
nmnher of system operations that can be t^ompleted in each 
cycle to give tlie total number of implenu^ntatiun cycles. In 
the example used to illustrate the planning procesSj the esti- 
mated length of the implementation phiise is 32 weeks. To 
faciOtate communication, it is useful to assign thenies to 
each of the impiementatioji chimks. The project team and 
the users will need both a detailed and a high-level view of 
ihe project, but there are tyiJically many tneinbers o( the 
organization that prefer to see just llie "big picture." The 
thenies ckm help convey that big picture. 

With the dehverables now defined for the first several EVO 
cycles, the technical lead can prepare the detailed task hst 
for tliese cycles. This detailed l^^Lsk h.st sliould include a clear 
description of tlie task, an owner for the task, aiid any de- 
pendencies that the task may have on other tasks within the 
cycle. 

It is not necessary to provide any additional detail for the 
groupings of use scenarios beyond the first. It is only neces- 
saiy to make sure that all fmic tionahty us it is defmed at this 
early stage is accomited for and thai an overall estimate of 
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Uie effort is calciilaied. II is expected rhai experiences from 
the first few implementation cycles will affect future cycles 
In majiy ways. These later implementaTion cycles viill be 
dermed m more detaO several cycles before theii- start date. 
On small projects w1tli one or two collocated teams, detajliiig 
the next three or four impleirtentation cycles is ad equate- 
On larger projects, it may be necessary to maintain detailed 
schedules that reach further out in time. 

Some of the rriteria commonly used in setting prioriliea dur- 
ing this initial] piaiming acti\ity aie the following: 
• Features with greatest risk. The most common criterion 
used for prioritizing the development phase impiemejuation 
cycles is risk. WTicn adopting object tet^hnology, nnmy teams 
i\TV concerned that the system perfonuance will not be ade- 
quate. Ease-of-use is another common risk for a i>rojecl, 
Tlie me scenarios that will provide the best insight into 
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areas of greatest risk should be scheduled lor mtpiementa- 
tion as early as possible. 

• Coordinatiori with other teams. Most so ft w are development 
teants today have conunitments to or are dependent on 
other teams. For example, fimiware tieveloiHivent depends 
on some form of hardware developmenh Reusable software 
platfonns make a strong commitment to the products that 
are built on them, it nmy be necessaiy^ to ac^jitst the pilority 
assigned to functionality to accommodate these dependen- 
cies and conTmitments. 

• "Musi have" versus "want" ftmctionality. All product fea- 
htres are not created equal. Some features aiT considered 
critical to the success of a project, while sonve features 
would simply be nice to have. Some developr\ient projects 
nmst meet well-defined standards and may even have to 
pass certification tests of their functioriahty that are defined 
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by governing regulatory agencies. On these projects, it \s 
often Jh\sI to eoni]ilete the lefpiired or ''miist liave" fiin< tifjn- 
ality before the value-acirleti or ''want" fimctionaUty, 'I'liose 
use scenailos that capture the reqiiire<l fiinetinruillty should 
be given liiglier priority tliaii ltix)se that capture* only desired 
fimctintiaiily 

This sariie <.Ti!eiiou vnu also api>ly to cure or fiiruturiK^oLal 
functionality that nuist be in place before atklilioiiaJ func- 
tionality can be implemented. It may be necessary to build 
up in a layered fasliion the core funcliojuility that aJI other 
huiciion ality will depend on. It is imperative that each cycle 
contritjutlug to the core fuju tioiiahty be defined so that 
sonie vahdation or feedback can be obtained, 

• Most popular or most useful features llrst. If project risks 

ar e minor and if project conimitments and dependencies are 
insignilicajil, then prioritization of use scenaiios can be 
based on value to tlie intendeci user. Those use s{:^enai'ii>s 
that aie die most populai" or will he of die most value to the 
user should be completed firi^i. 

• Infrastructure developiTient J Asiguincani amount of devel- 
opment environment infrasinicture nujst be put in place 
during the first few implementation cycles. The tools thai 
will be used, siu"h as the compiler, debugger, and software 
asset configuration managt^i; a.s well as the processes thai 
ai'^' adopted, can be devt^loi^eil in lU) evolutiotKuy fiishitjn in 
paiaMel witJi die functionality intentled for the user, Sotne 
tetmis have found it valual>le to make the uifrastnictuie tasks 
^m exi>hcit category m the plan for each implementation 
cycle, 

DeveJopnient Phase 

With both the develofjuient phase plan aiid tlie detailed plans 
for the first few EVO cycles in place, the imi^lemerttaiion 
process can begin. Each EVO cycle consists of tJie same 
basic steps: lefiuuig the analysis models, developing the 
design models, and writuig and validating the code. The 
customer feedback process is executed in paj'^dlel wit h 
these tasks. The deliverables from the previous EVO cycie 
aj e evaluateti by selected users or tlieir siu'rogates, tmd deci- 
sions are made that shape the content of the subsequent 
EVO cycles. 

Refining the Analysis Models, The EVO cycle begins vtirh a 
re\ icw of the existing Fusion analysis models agtiinst the 
functionality or systent operatiotis defined cis deliveiablcs 
for that cycle. For each cycle, new functiouidity may be de- 
fined for delivery and existing functionality ntay be identi- 
fied for modification. 

The process for moving througli the Fusion analysis modeis 
remains the same. Use scenarios that mclude tlie system 
ope rat it) ns must be re\iewetl for changes that were the re- 
sult of feedback and re tine men 1 fi'on\ previous EVO cycles. 
The object mode! must be reviewed for similm^ char\ges. 
Additional detail may be required in the object model. Tlie 
system operation descriptions aie reviewed for any changes 
and to ensure a common understanding by all members of 
the leaju. 

The technical lead is a key player chiring Uie refir^ement of 
the analysis modeis. Because they reprcMsenl the overall 
architectiu'e for the system, any extensions or enlian cements 
of the models must be made wiUiout serious compromise to 
the integrity of the architecture. If compromises must be 



made* they should be logged as defects against the an-hitec- 
ture and « considered for possible repair m a later EVO cyele. 

Design Modefs. Based on the clear understanding of the de- 
li verahk's for tile cwcle general f»d by the review iind refme- 
trient of the analysis nujdels, the P\ision design nujdeis can 
be created or uptlated. Object interaction graplis will deter- 
mine the new classes tliat mil be needed or the new methods 
thai will be added to existing chisses. Tlie Fusion design 
modeis determine what coding must be done foi' the cycle* 

Coding and Validation. In addition to the code timt must, be 
generated to implement the design models, miy tests needed 
to validate this work in later cycles nujst also Ije completed. 
Many teams make use of test harnesses to validate their 
code during tJie early cycles of de\elo]imenf. These test har- 
nesses ai'e software modules or suhsysiems that can exer- 
cise the method interfaces of otlter software sutisystems. 
They me particularly useful d tiring the early t^ycles of devel- 
oprnetit when rtii\jor tjortions of tlie luchit.ecture have not 
been implemetUed. They also provide great valut* in later 
EV<:) cycles as tools for focused and automated regression 
testing. 

Customer Feedback. The customer feedback loop operates 
simultaneously with the implementation tasks. Beginning 
witli the second cycle and continuing throughout the devel- 
opment pluLse, some group of users or surrf igat e users will 
be validating the product thai the team luis < ouipleted so far. 
The feedback that they provide must be evaluated against 
the vahie proposition of the project for approj)riate decision 
nmkirig. It is impoitarit that the project manager, lechnic^il 
lead, arul ust^r iiaist>n allocate enuugh time (haing each cycle 
to review i)ians, ijroeesseSj and architectural docmnents to 
assess the imi^aci of each decision. 

System Test Using Use Scenarios, .Mliiough the use scenarios 
i-an l)e lic^Hul in cuiidnc ting unit and integration testing for 
each im[>leituMilaiif>n cycle, they CcUi provide the greatest 
value tlurijig systern test. Since the use scenaiios are not 
structured along ai'cliitectural or subsystem boimdaries, tliey 
tend to pro%ide a broad level of system testuig that generates 
paths of execution tlirough the entire ,systc[n. Tlicy may be 
augmented to generate boundar^^ and stress-test conditions, 
and they can also seiA^e as a luasis for creating user-level 
documenlation. 

Scaling up for Large Projects 

In the use of Evoiutiooaiy Fusion with large projects. an<l 
especially witii those that include multiple development 
teams that may not even be collocated, there are a number 
of additional issues to consider It may not be appropriate to 
integrate the delivei'ables from all i>rojeel teams ev^eo" EVO 
f. ycle. [\ is useful to define a higher-level set of EVO cycles 
ami to integrate all work together at the end of Ihose cycles. 
To mmiage These nndtiple levels of F]VO cyx-les, as well as 
the broad set of technologies thai may be involved, it is also 
useful to employ multiple technical leads, or arcMtects. 

Hierarchical EVO Cycles, As the size of a project team gro%vs. 
a larger and huger portion of the standard GVtJ cycle is dedi- 
cated to integrating the work of the many project team 
members. To keep the standmtl EVl) cycle as small and as 
efficient as possible and to let pnjjecl teams progress iu 
parallel, it is necessary to mtroduce hierarchical EVll 
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Fig. 1 1 . H it' rar chlcal E\'(J Cycles. 

cycles. These hiemrchical cycles are essentially a fornializetl 
version of the chunks of functionality or groupings of use 
scenarios introduced earhen under "^Grouping and Prioritizing 
f\inctionaiily." 

Tlie fonr or five ni^or ehimks or groupings that the use 
scenarios are imtiiiily broken into become the highest-level 
EVO cycles. As before, the use scenarios for the firet chunk 
or EVO cycle are sequenced ai\d the system operations allo- 
cated between nniltiple teams (Fig. 1 1 ). For lai-ge tejmis, it is 
also itseful to add an hitegmtion EVO cycle at t±it* end of 
each nxtyrn' EVO cycle. 

Each teani is exjjected to define its own user feedback and 
^^alidatiou process for Its minor EVO cycles. There will also 
be a feedbac k i^uid %'aiidation process for each niiyor EIVO 
cycle of the system. 



Role of Architects. Since it is difficult to define subsets of 
fimctionality I liat are completely independent of one another* 
it is uitportant lo have an identified indi\idiial or group of 
indi\iduals tcj niajiage tlie dependencies thiouglioui each 
mj^or EVO cycle. Tliis role is best played by the teclmical 
leads of each team, die architects. The architects i)lay a key 
role in ailocatuig system operations iunong the various teams 
during each plaiming phase, ajid tliey ai*e best positioned to 
resolve any lechnicai issues that emerge as a result of the 
pm'allel ijnplementatior^ ajjproach. For large projects within 
Hew let t- Packard, w eekly meethigs or conference calls are 
typicid for the architect teams. 

ConcluHion 

Much of Hewlett-Packard's success is attributable to the fact 
that it is a diverse company composed of many independent 



Fusion in the Real World 



The use of Fusion has spread rapidfy since its introductian in 1993. 

Today, it is the most widely ijsed object-orientod analysis and design 
method in Hewlett-Packard. Many other companies worldwide are also 
employing the methmJ on a wide variety of applications and products. 

Fu^sion is a tiving method that is being extended and evolved based on 
lessons learned in the real world. Todd Cotton's work on Evolutionary 
Fusion, described in the accompanying article, is an exemplary illustration 
of how Fusion benefits from the collaboration of a broad community of 
users, consullams. and researchers. The book listed in reference 1 was 
created to provide a forum for articulating and disseminating such con- 
tributions to the method. It does this by collecting together reports from 
the field that describe the practical lessons that have been learned from 
projects using Fusion. Todd Cotton and other contributors combine their 
expertise id give the most comprehensive look yet at how Fusion is 
changing the worfd of object-oriented development Throughout the book 
the emphasis is on practicality and lessons learned. The main themes of 
the book mctude: 
• An introductory overview of Fusion together with full reference 
documentation 



• Detailed experience reports of industrial projects discussing how 

to introduce Fusion to a project and how to succeed using it 

• An account of how to reduce risk by integrating Fusion into an 
evolutionary life cyle 

• A report on metrics and defect tracking in a Fusion project 

• lessons learned from a wide vanety of applications and backgrounds, 
including product development organizations, research laboratories, 
academia, software houses, and consultancies, 

Ruth Mafan 
Software Engineer 
Hewlett-Packard Laboratories 

Reed P Lstsinger 
Project Manager 
Hewlett-Packard Laboratories 
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organizations. However, relatively few software develop- 
ment best praetiees Imve arhievecl widespread adopt ioi\ in 
this en\ironinenl of aulonomy arut diversity. Fusion appe^irs 
to be ail exception to this nile. Fusion's appeal m largely a 
result of the respect that its creators have for software de- 
velopment teams. Fusion does not attempt to address every 
jiossible nuance of software development with complex 
notations and model variations. It does provide a reasonably 
simple, compiete set of models that supports a team througli 
most of the develoijnienl jjrocess, acknowledging that soft- 
ware engineen^ are higJily educ*ated and talented profession- 
als and tliat they are best suited to adapt a melhod to meet 
their unique project needs iu\d working siyk^s. 

Evolutionary Development has been positioned here as a 
life cycle for software development, but it really has much 
broader application fr> any complex system. RLsion, the 
method, is changing to 1 letter meet user needs u.sing an evo- 
lutionary approach. Based on user feedback, we merged 
Evolutionary Development with Fiision as the deliverable 
from one evohitionaiy cycle, Tliere have been a number of 
other changes to the methofl, as well as to the method of 
dehveiy, agaui all based on user feedback. As our experience 
with Fusion grows, so will the method. Il is our lntj)e tliat 
the Fusion user community will continue to shaie exiieri- 
ences kmd to e%olv(* tJie methcKl m a direction tltai is both 
respectful aiKi useful to aU software development teams. 
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The Evolutionary Development Model 
for Software 



The traditional waterfall life cycle has been the mainstay for software 
developers for many years. For software products that do not change very 
much once they are specified, the waterfall model is still viable. However, 
for software products that have their feature sets redefined during 
development because of user feedback and other factors, the traditional 
waterfall model is no longer appropriate. 

by Elaine L, May and Barbara A* Zimmer 



Hewlett-Packard, like other organizations developing soft- 
ware products, is always looking for ways to improve its 
software de\x"lopmeiU processes. One sofhviire develop- 
ment niel hod that has become quite popuhir at HP is called 
Evoiationart/ DpveiopniPni, or EVO (see reference 1 and the 
article on page 25). EVO uses small, incremental product 
releases, freqneni f lei i very to users, aiid dynamic piajis and 
processe*?. Although EVO is relatively simple in concept, its 
implementation at HP has included both significant chal- 
lenges and notable benefits. This paper begins witli a brief 
discussion aboul the EVO method and its benefits, tJien de- 
scribes software pnyetis at three flP divisions that have 
used EVO, an(! finally discusses (critical sucre«is faflors aiid 
key lessons about BVO, 

The EVO Method 

Fig. 1 shows the difference between the traditional waterfall 
life i^ycle ^md Ihi- EVO life cych>. Tlie EVO flev(-lopment 
model diviftcs the dcvelopjopnt cycle into smaller, incremen- 
taJ waterfall models in which users are able to get access to 
the prmiuci at the end of each cycle. The users provide fetni- 
back on the product fur the phmning stage of the next cycle 
iind the develojnncrit learn re.^|K)rids, often by changing the 
product, pkms^ or process. These incremental cycles are 
typically two to four weeks in duration and continue until 
theprodud is shipped. 



At Hewlett-Packard, we have found tliat it is possible to 
relax some of our original ideas regarding EVO. In particu- 
lar, il isn't absolutely necessaiy to dehver tlie product to 
external customers with customer-ready documentation, 
training, and support to benefit from EVO. 

Benefits of EVO 

Successful use of EVO can betieHt m:>! cmly bushiess results 
but marketing ^md Lntenial o[>eratioas as well. From a busi- 
ness pers|>er!i%'e. rJie biggest benefit t)f EVO is a significant 
reduction in risk for software projects. This risk miglit be 
associated with any of the many ways a software project 
caji go awT>', including missing scfvedulcd deatUines, unusable 
products, vvTong feature sets, or poor uuality By breaking 
the project into smidler, more manageable pieces iind l>y in- 
creasing the vlsibilitj^ of the numagen\ent lemn in the project, 
these risks can be addressed and managed 

Because some design issues are cheaper to resolve througli 
experimentation than through analysis, EVO can reduce 
costs by providing a stnicturerl, disciplined avenu<^ for ex- 
jierimentatitjn. Fintdly, llu^ inevitat>h* change in expectations 
when users begm using the sofiware system is addressed by 
EVOs early aiid ongoing invohetnent of the user in the de- 
velo[>ment pnx^ess, Tliis can result In a product that hett^er 
fits user needs and market requirements. 
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Fig. 2. Amount of user fppdback fliiring (a) the traditional waterfall 

flevelopmfnt process and (b) the evoliiLionar>^ development process 
(EVO). 

EVO allows the marketing department access to early deliv- 
eries, facilitatiiig development of documentation and demon- 
strations. Although tJiis access must be given judiciously, in 
some maikets it is absolutely necessary to stait the sales 
cycle wel] before product release. The abi!it>' of developers 
to respond to market changes is increased in EVO because 
tiie softwaie is coohnnously evohing and the development 
team is thus better positioned Xa change a feature set or 
release it earlier 

Short, frequent EVO cycles have some distinct advaiUages lor 
internal processes and people considerations. First, contmu- 
ous process improvement becomes a more realistic possibU- 
ily with one-to-fom-week cycles. Second, the oppoitimity to 
show their work to customers and heiu" customer responses 
tends to incre^ise the motivation of softwtu'e developers and 
consequeiUly encourages a nK>re ciistomer-foeiised orienta- 
tioiL In tradilioiiaJ software projects, that customer-response 
payoff tnay only cojT^e every few years aiKl may be so filtered 
by market iitg antl luarmgeinent tliat it is nieaningless. Fig. 2 
illustrates the difference l>etween the tiadiTional life cycle 
and EVO in terms of how much user feedback can be ex- 
pected during product development. 

Finally, the cooperation and flexibility required by EVO of 
each developer results in greater teamwork. Since schedul- 
ing and dependency analysis are more rigorous, less dead 
time is spent waiting on other people to complete theu" work. 

While the benefits can be substantial, implementation of 
evolutionary development can hold significant challenges. 
It requires a fundamental shift m tlie way one thinks about 
managing projects and defuiitely requires more management 
eflbrt dian traditional software development methods. The 
next section exiunincs how EVO was applied in tluee differ- 
ent HP divisions and what we learned from tlie expeiience. 

Evolutionary Development in Practice 

Some fonii of EVO has been used in at least eight Hewlett- 
Packard divisions in over ten nuyor projects. Much of this 
has been done drawing on expeHlse from HP's Corporate 
Engineering software uiitiative* which is a central service 
group of consultants in software engineering and manage- 
ment (see the article on page 42). Tlie softwaie initiative 
group is currently leveraguig existing exjierience and pro- 
moting the use of E\'0 at HP. 



The three divisions described below are in three entirely 
different businesses. While all the product names used in 
Ibis paper are fici itious, the case descriptions are real. 

First Attempts 

The first jiroject was undeiiaken at HP's Manufacturing Test 
Division. The project (called project A liere) consumed the 
time of four softw^ure developers for a year and a lialf and 
eventually was made up of over 120,000 lines of C iind C'++ 
code. Over 30 versions were produced during tlie eleven- 
month implementation phase wtucli occurred in one- and 
two- week delivery cycles (see Fif^. ;i). The primary goals in 
using EVO were to reduce the number of late changes to the 
user interface and to reduce tlie number of defects foimd 
during system testmg. 

Project A adapted Gilbs EVO methods.* One departure was 
the use of suiTogate users. The Mtmufacturing Test Divisiou 
produces testers that are tised in manufacturing en\iron- 
nienls. If the tester goes down, tlie manittaci urer cannol 
ship products. Beta sites, even when customers ^ree to 
them, aa^e carefully isolated from production use. so the beta 
sothfvaie is rai'ely, if ever, exercised, Poinnnately, the project 
had access to a group of smTogate users: apphcaiion er^gi- 
neei^ in marketing and test engiJieers in iheir own manufac- 
tming depaitmenb The use of siurrogates did not appear- io 
have any negative impact- 
About two tliirds of the way through the project, the rigorous 
testing and defect fixing that had been done during the EVO 
cycles was discontinued because of schedule ijressures. The 
cost of this decision was quality. With ail efforts focused on 
ilnishuigj developers began adding code at a rate double that 
of previous niontlis, and over half of the critical and serious 
defects were inl roriuced hi to the code in the last tlurd of the 
project schedule. 

Even though EVO was not used to complete the project, the 
pro<iuct was successful ^uiti the team attiibuted several posi- 
tive results to having used the EVO method for the ma,jority^ 
of the project. First, EVO contributed to creating better 
teamw^ork with users and more time to tliiiik of alternative 





Development Team 


Users 


Monday 


• System Test and Release Version H 

• Decide What to Do for Vers ran K+1 

• Design Vers iart H+1 




Tuesday 


* Develop Code 


■ Use Version H and 
Gtve Feedback 


Wetliiesday 








• Develop Code 


Meet to Discuss Aclion Taken Regarding 1 
Fecdbnck From Version N-1 1 


Thursday 


* Complete Code 




^HHj^l • Test and But^dVemron N-i-f 
^^^^^^1 • Analyze Feedback Fram Version N 
^^^^^1 and Oecide Wli@r to Da ^ext 





Fig. 3. An {'Sample of a [jTical one-week E^VU cycle at tlie Manu- 
facturing Test Division during project A* 
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iQlutions. Second, the prqject still had signiScantly fewer 
critjca] and serious defects dining s^-stem testing. Third, the 
team was surprised to see an mcrease in produc(i\ity { mea- 
surei! in KNCSS per engineer-nitonth ). The project nianager 
anributes tJiis higher productivity primarily to increased 
focus on project goals. 

Despite having abandoned the E\^0 method in project A, 

many in the ditision felt thai because of the benefits derivetl 
from the ntef hod. they should pve it another tr>. fVojecl B, 
the second projetn to use liie EVO metJiod. involveri creating 
custom hardware with a team of three project managers and 
20 engineers. The project required significant changes to over 
1.5 million lines of code. One project manager coordinated 
the efforts of three development teams. 

The primary^ reason for using EVO for this project was lo 
demonstrate tlie feiLsibllity of the product's new test terlv 
nique f lirough the use of beta sites. Internal usei"s were used 
early in the cycle and external customers became involved 
with later versions. This decision resulted in actually selling 
systems to beta-sile customers. Further, the traditionally 
long startup lime for the di\1sion s sales cycle was shortened 
signiScantly by the use of EVO atui \^]idatton of the product 
by users (see Fig. 4). This created a ttvtyor business imi>act 
since it ty|>i€ally takes nine to Hfteen months before the 
market believes a prodiirt of tJiLs t>pe can live up to its 
claims. Even more time passes before customers will actually 
buy the product. Because EVO encourages early exposure of 
a pi oduct to users, sales started even before the product 
shipped! 

Start Small 

Tlie experience of MPs Personal Software Division with 
EVO JiLso l.>egan with some staitup prol^lems. folk i we'd i)y 
remarkiible succt*ss. The fiiiil project to use EVO was chosen 
because it was fell that EVO would help to prioritize new 
features, respond quickly to customer needs* and, because 
of ElVOs many rele^ise cycles, enable th(* release of the soft- 
ware i>roiiucl at any time in response to conii>eUtion. 

The six to eight project majiagers and approximately 60 
engineers on this project were all new to the EVO methofl. 
The plan was to do a complete release, including customer- 
ready docuinenlation mid sujiport^ every month. Unforiu- 
nately, tht^ first release consisted of paper prototypes and 
tlie users were not able to provide good feedback. TTie sec- 
ond release used real code, took sisc weeks rather than the 



four weeks scheduled, and EVO was generaUy thought not 
to be worth the integration and logistical effort- For this 
reason* the division decided to abandon EVO. 

.Although EVO had a bad reputation at the division after the 

first project, in a smaller follow-on project, one project man- 
ager and eight, engineers decided to try^ their owti variation 
of E\'0, calling it ''phased development " During the iirst 
one-month phase, the developmeni team worked from .static 
vistial designs to cwie a proititjpe. In ftx^us grouj) meeongs. 
tlie team discussed users' needs and tht^ poiemial features 
of the product and then showed a demonstraiion of its 
prototyT>e. The excellent feedback from these focus groups 
had a large impact on the quality' of the product. 

After tJie second cycle of focus groups, the feature set was 
frozen and tlie product definition complete. Implementation 
consisted of foirr-to-six-week cycles, with software delivered 
for beta use at the end of each cycle. The entire release took 
10 months from definition to manufacttiring release. Imple- 
mentation lasted 4.5 niojuhs. The result was a world-class 
prodiui that has won matiy awards and has been easy to 
support 

The success of phased development for this second product 
led to tlie use of a similar process in the second release. Tlie 
project manager concluded that the phased development 
process was the best apfiroach for jirojecLs witli an aggres- 
sive, user-driven schedule. Team ex^ierience and confidence 
were definite contributirtg factoi^s to the product's success^ 
and a compelling product vision proved to be absolutely 
necessary. 

Several potential issues arose during the project. EVO can 
ad<l overhead, i)artJcularly in small one- or twx^person coni- 
|>onents. Tliis is mainly because of the need for mpid c*on- 
text switching between v'arious activities. /Vno t her poteen I ial 
]iroblem is the mnoimt of time consmncd by evaluation, llie 
team is inv^esli gating how to make evaluation feedback more 
ttmelv A third issut* is tlie need to schedule enough time for 
front-end activities like design itnd inspections. Scheduling 
longer evaluaHon cycles at the begi ruling of a tiew release 
could accommodate this, as could setting aside iTiterntediate 
cycles ffir design, inspections, aiid code cleiuiup. 

The project postmortem listed a number of benefits from 
using EVO. The team particularly liked seeing the results of 
their work often. Otlier benefits included: 
• Ijong-term vision broken ittto short-term steps 
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• Prioritized implenienlation within component teaniis 

• C'ross-funriioiuil, empowered conipojtenl leams (detlsion 
making pushed down to the project engineers) 

• Early results — good commnni cation tool inside and outside 
the division 

• Kxtemal customer feedback 

• Six- week pUmning at the system level 

• Excellent for incremental improvements to existing 
products 

• Karly realism about how iiuich can be done, 

A New Platform 

Tlie last pr< jjeci described in this article involved one project 
manager and eigln enj^irieers from f IP's Microwave Instm- 
ment Division. It was a firmware project to Imild a platform 
for developing new products. 

Since a reusable platfonn design was a new way of working 
for the tlivision, the EVO metjiod wajs exrjccled to ge1 more 
visibility (\ia frequent flelivery dates) for constnK tion of the 
prototyjje. The platform team expected to get good feedl>ack 
from the teams developiug the follow-on projects. The proj- 
ect uumager had strong reservations about using EVO and 
about being able to province a verifiable slice of \he plai- 
form architectme in six weeks. Tire project manager de- 
rided to give EVO a tjy even if it seemed that it wouki take 
ten weeks to complete tire feasibility demonstration work. 
The team completed the bulk of the feasibility work six 
weeks into the project aird linished it all by the runth week. 

Some engineers imri^illy struggled vvith breaking tlieir work 
down into two-week chunks. Eventually they not only 
learned to do it but saw some real value in doing it, such as 
getting better estimates so they could meet their commit - 
ments ajid htmdle coordination and linkages with tlie rest of 
tJte teanu 

The team members also btmeflted from using EVO \o de- 
velop theu' software development environment. Because of 
tJie improved infrastnictnre, the project team was able to 
train new engineers quickly on the new platform develop- 
menl ijaratligm. Tlie project manager reported much greater 
uisighl inio the progress of tlie team and felt better able to 
manage the project. EVO helped to vmc<:jver key issues early 
and focus attention on the right things. One-third of the way 
tlu'ough the project, the team was able to verify and meet 
their fu-st ])eifom^ance goals. Traditionally tliis ditin'l happen 
until at least halfway through a project. 

Unfortunately, after completing more thim half of tJie planner! 
cycles, the project was cancelled because of a shift in the 
division s shoil-temi RM) strategy. The lab currently plans 
to use FIVO in rw-^o new projects. 

Critieal Success Factors 

Based on accumulated HP experience in evolutionary devel- 
opment, including \he three division experiences described 
above, we have compiled a list of critical success factors. 
Since not eveiy project is suited for evolLUionar>' develop- 
ment, tlie following success faclons provide some indicators 
for deciding if a project Is a good candidate for EVO. 



The Software Initiative Program 

HPs Corporate Engineering software inittativB (SWI) is a major corporate 
effort to make software development a core competence at HP Drawing 
on the expertise of its members in software engineering, management, 
and business methods, the SWI partners wiifi product develDpment orga- 
nizations, delivering knowledge and expertise in key software compe- 
tence areas to get more products to market faster* with lower costs and 
higher quality. 

SWrs mission is to foster sustainable breakthroughs in product genera- 
tion capabilities fof HP's business goals as related to software and 
solutions. To achieve this, SWI consultants' work is driven by customer- 
directed outcomes, In practice, determining what these outcomes are Is 
often in itself a significant contribution to the customer organization and 
is the first step in any SWI engagement. The SWI team works with multi- 
ple levels of group and division management to understand the entity 
business goals and explore ways of gaining competitive advantage. 
These goais. along with challenges or obstacles that need to be consid- 
ered, drive the creation of specific improvement plans. 

SWI's value is in its ability to accelerate software development and re- 
duce the risk of having to make fundamental changes to existing software 
devefopment and management practices. SWI is currently partnering with 
product development organizations in all of HP's business sectors This 
includes significant efforts focused on software reuse, platform develop- 
ment, and testing. 



Clear Vision 

Pel haps the most crilical sure ess factor in usijig EVO is hav- 
iiig a t'lt^iir and competiing \ision of tiie product. Tlie per- 
ceiverl vision or valiie of tlie product is the reason why 
someone would buy a given product ratJier than anothtTj or 
buy no product at alf Wtiether addiJig incremental function- 
ality to an existing product or developing m^jor new compo- 
nents or functionality, the project team needs to understand 
and accept this \ision. 

This vision w^itl help guide prioritizing and decision making 
and will make It easier for users and developers to uruler- 
stand why some ctianges are approved and others are not. 
The project manager at the Pergonal Sofh^^are Division noted 
that the lack of clear focus for the second version of the 
product made the project itiuch more difficult to manage 
tliLm tiie fii^t release. A cleai* vision is critical to convergence 
on a releasable product. 

Project Flaniiing 

Three fact or s neeil special consideration in planning EVO 
projects. Fii^t. managing an evolutionary development 
project requires sulistantially more effort, than managing a 
traditional waterfall development project. The contents of 
each deliveiy shoukl be planned so that no developer goes 
more tlum two releases without mput lo a release, Tlie goal 
is to get everyone on I he project temn developing mcremeih 
tally. .\1 though it is difllcult and time-consimiing, the woi k 
breakdown structure and deperidency information must be 
done and done c:orrectly. 
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In addition to more management effort, EVO also requires a 

fiindamental shift in how we thdnk atioiit soRware de\'elop- 
ment. TradirlonaUy. rhe first tiiird of a project is spent 
getting the infrasmicture in pla<^e before developing any 
ciisiomer-%Tsible capability' Tliis is a problem for an E\T) 
project because E\'0 requires eariier development of 
cnBtomer-^isible functionality to elicit customer response. 
Delaying customer mieniction \^ith a pnxlucr until the sec- 
ond third of the project is incompatible vfith this objective. 

Tl^e solution topically hes in finding some existing code to 
leverage. Althougli there is almost always resistance to 
using this approach, it is usually possible to find something 
to leverage. If tlus is not possible, then thiiilc about implex 
menting tJie inrrasinicaire in an e^^olutionaiy^ niaiuier In any 
c:ase, tJie first deliverj' should be released in no more tlian 
tw^o EVO cycles (see Fig. 1 ) from the start of implementa- 
tion. Tlie first reason for this is that many of the concerns 
(ieveiopers Imve with evolutionary^* development are best 
addressed by doing EVO. Second, if the start u\' EVO deliver- 
ies is delayed too long, the risk that delivei>* will never 
happen (until manufacturing release) is increase<l. 

The OnaJ pUmning recommendation is to create a standaid 
development plan that can be used for each cycle. Having 
the same activities occur a1 I he same time within each cycle 
helps teaju members get txgiuiixed dud makes piocess im- 
provement easier. Tlie activities of three groups should be 
planned: developers, [Lsers, atxd the group who will make 
decisions about user feedback. Keeping tlie cycles short 
helps kee|> the developer^s motivated to make changes in 
response tr:) customer feedback. 

FiU Key Organizational Roles 

The uniijm' needs <jr EVO jjroJecCs require two additional 
key project roles lo l^e tilled: tcchriical nianager ;trMl user 
lijiison. Because* of the extra manasemeni burden imposed 
by EVO, it is useful to have one of die tn^girteers act as a 
technical manager. Tliis person is responsil>le fordevclopinj^ 
the EVO [>lim (with the project maitager) ami keeping (rack 
of the progress of the grouts The technical tnmiager is key 
to moving the project for\^ mtl, resolving daily lactic^il is,snes, 
and handling nuis! coordination activities, with the mmiagc- 
rnent team as hackup. T^^iiciilly, techrihrri! niarrnj^t^rs ulso 
1 lave d e vel cjpme n i re s j j oi i si hi I i t i es. so 1 1 icy l ei i d to un d e r- 
sland the dependencies between tasks and can relate more 
freely to the otiier engineers. 

The other key position, user liaison, trains users, collects 
their feedback, and conmiunicales changes in the status of 
the project. The user liaison is the single point of contact for 
all the users and developers. This peiTw^n should lie the first 
one to use each delivery to see what has changed and if 
there iirt^ ajiy probleuLs in the code. Tiie liaison's jcjh is to 
make il *»asy for users to be ijwolved in die project. A strong 
user afhxMjite in tJiis role can also contril>ute to mimagement 
decisiuns. VViflioul this role, conmiunication betvLcen the 
developers and users can be haphazaRl, inefficient, and a 
m^or energy drain. 



Manage the Developers 

Although evolutionary^ devek>pment may seem inttutively 
ob\ious, implementing it in a traditional software life cycle 
en\iroTmient should not be undertaken hghtly. Much of the 
challenge has to do with managing people. TT\e following 
steps have also contributed to success at HP: 

• Estal»lish a credible business reason for using EVO 

• Discuss the method and the rationale for using EXO with 
the development team 

• Ask for feedback 

• De\ elop an imtial plan thai addresses as many concents 
as possible 

• Mk ihe development team to tiy EVO for a couple of 
releases and then evaluate future use. 

Two nuyor concerns arise in mtmaging de\ elopers. The first 
is a concern that the developnieni effort will degenerate into 
hacking. To i>revent this, the software archiietture must be 
well-j>artiUoned ai^d loosely enough coupled ia enable easy 
UK >tlifi tuition. Tlus is why object-oriented progranmiing tech- 
niques are particularly weli'Sutted to ev^olutionary develop* 
meat, hi addition, one or more persons must be assigned to 
maintain aixluteclujal integrity, imd if substantial redesign is 
required, time must be scheduled. This should be a m^jor 
consideration in determining if a project is appropriate for 
EVO methods. 

A second concern is that it \vi\l he too difficult to make so 
many releases. If it is difficult to make one release every 9 
to 18 montlis, how much more difficult will il lie to release 
every tw^o weeks? Tlie ^mswer is that when you make fre- 
quent releases, you get better at it (if this is not the case. 
EVO becomes too inefficient). Further, the small chunks in 
each cycle keep things to a manageable sl:£e. 

Be aware of a few potential problems that couk! rwi^ke man- 
aging developei"s diffirnll in die imidementalion tihase if not 
addressed |>r(»perly. First, users tend to focus on what diey 
don'l like, not what they do Uke. To keep this from i>eing 
dis<' on raging for the developers, it might help to provide a 
standard feedtiack form that elicits "Things 1 liked" follt>wed 
l.'iy ''Things 1 clidn't hke.'' Because many more project miinage- 
ment clecis ions need ki be made in EVO, fuuulling flecisions 
caji also beconu* a problem. If the decisions are not timely 
or cause dissension, pixigress can be delayed- Participatoiy 
df^cision-makirvg teciuiiques have been one solution at HH 
Finally, developer overwork or Immoul is a potential hazard. 
Most developers overestinmte the amount of software they 
can write in one or two weeks. Wliiie working long hours 
may seem attractive for a short period, it will ultimately he 
destructive. 

Select and Manage Users 

E vn hit ionaiy ( 1 ewA o t > m i ■ u I r* ^c [i i i res users to exerci se each 
deliver^'. Mmiy piili ntial users have been alienated in the 
l>ast by the inability of developers to respond to their feed- 
hac k in a timely mamier Additionally, users are usually 
l)eing asked to do a task above mid beyond I heir regular 
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Jobs. Consequent ly, the selection, care, and t.rt^atment of the 
user base is a l<ey Issue for an EVO project itiariager. 

The source of the user base is the first issue to address. 
ExtemaJ customers (through field organizations J, internal 
ciLstomers. marketing or field people, ajid teniporary workers 
have till been tisetl successhilly to lest products. The closer 
the project team gets to extc^niai ciLstonier^, IJie niore accu- 
rate the feedback Lends to be, but the more difficult the ciis- 
tomer-relalions sUualion becomes. Several pnjjects satlsfac- 
torOy used intenuxl sun ogate users for early releases and 
then shifted to extenial cnsiorners. 

The user group should have a mix of customers that are 
representative of the target market. Tlie group must be big 
enough ho tliat one person doesn't skew the results, yet not 
so big that nianagiixg users overwhelms the project team. 
Among The user expeelations that need (o be set are: 

• Time conunitmeiits to use the product and give feedback 

• The possibility of critical problems wirlt the software 

• Ttie possibilHy I hat th(* softw^aie may or may not change 
substantially durinj^ the project 

• Prohil>itton against discussing the software with anyone 
outside the project. 

If the user is an exteniai customer, the field organization 
must also be comfortable with tJieir involvement. 

In addition to setting expectations con-ectly, keeping users 
satisfied during the ilevelopment process is the other main 
challenge of mauaging users. An obvious way to keep users 
hapi^y is to give diem cotle IliaJ works reiisonabiy weU. If die 
eotle keeps failing, they will gel fmstrated and tend to sto|j 
using it. A second key to castomer satisfaction is to take 
theij' comments seriously and let tliem know what changes 
resulted from tbeir feedback. If a suggestion cmi't be imple- 
mented, cxjjlain why to rhem or, better^ yet, have one or 
more of the users involved in the decision- making process. 
Pinally, streamline the soft^vaie distribution ar\d feedback 
collection process. Find out what mechanisms customers 
like to use foi' installing the software and providing teefl- 
back. Then accommodate those desires as much as possible. 

Shift Management Focus 

Traditionii] software [.rioiect management focuses 95% of the 
team effort on shipping code. With EVO, it is iiuportant to 
focus attention equally on all three components of the pro- 
cess, as sbowii in Table L 



Table 1 

Management Focus during Traditional 

and EVO Life Cycles 


Activities 


Traditional EVO 


Shippmg Code 


«iSI 33% 


Getting Feedback 


2.5% 33% 


Making Decisions 


2.5% 33% 



Because of the need to radically shift the focus of all in- 
volved, gettmg feedback and maldng decisions in the early 
part of die project should be emphasized. Putting a lot of 
stRictiure aromid those two activities by douig such things 
as sehedidhig i-egulai" meetings to rc\icw feedback aiui 
make decisions will help ensiu*e that they get done. These 



two activities are prerequisite to getting real value from 
EVO. 

Manage Builds 

To do evcjhuionary development , a project team must have 
the abihty to construct tlie protkict rrequejitly. If the product 
will lie relciised everjf- 1 wo weeks^ develop(?rs should be able 
to do a miniunuM nf oue huild per wpck, and preferably a 
Ijiiild every otlier uighb The engineers must be able to inte- 
grate tbeir work ajid lest il, or they can*t release it. Code tiiat 
'iH t^hecked into the eon figuration management system must 
be clean, an<i (be build i>roce.ss itsell" mitst nm in 48 hours or 
less. Idennryirig a l>uikl engineer oi' ijitegrator can help the 
process. 

Focus on Key Objectives 

Wliilc there aie many reasons to use evolutionary develop- 
ment on a project, focusing on one or two en ileal benefits 
wiU help optimize effoils. These goals will j^uide later deci- 
sions such as how to stniciure iiser^ involverueiit. how to 
change plans h^ resj>onse lo user leetJback. and how lo orga- 
nize die project. Regardless of wlial goals are focused on, it 
is critical to communicate tJie reasons for slrategic decisions 
to both management and the development team. 

Evolutionary development is a different way of thmking 
about managing softwai'e tirojects. Most groups will probably 
exj:ierience son^e of the pain I Iial usually accompanies 
change, so start witli a small pilot project first and then try 
a larger project. 

Conclusion 

The evohil ionaiy development methodology has become a 
significant asset for Hewlett-Packard software developeis. 
Its most salient, consistent benefits have been the ability to 
get early, accurate, w^elM'onned feedback from users and the 
abihty to responti to that feedback. Additional advantages 
have come from the alMlily to: 

• Better fit tJie producl to user needs and market reqiurements 

• Miuiage project risk with deHnition of eaily cycle content 

• Uncover key issues early and focus attention appropriately 

• Increase the opportunity tn liit market windows 

• Accelerate sales cycles with early customer exposure 

• Increase management \tsibiljty of project progress 

• Increase product team producti\ity jmd motivation. 

The EVO method consists of a few essential steps: early and 
frequent iteration, breaking work into small release chunks, 
phuuiuig short cycle times, and gel ting ongoing user feed- 
back. Other components can he modified to acconmiodate 
tlie needs of specific projecls, products, or environments. 
Examples where situation judgments are appropriate uickide 
selection of users and length of cycles. 

Additional acti\ilies, like establishing a clear product \dsion, 
identifying a lechnical manager and user liaison, creating a 
standaril de\ elopment plan. an<i setting conect user ex- 
pectations, wdU help optiniize rhe bene 11 rs of using EVO. 
The challenges in using EVO successfully arc mostly, but not 
exclusively, himian resource issues. Tliesc uiclude the shift 
in thinking about a new^ project structure paraciigni and 
f>erceplions that EVO requires more plamimg, more liisks to 
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track, more decisions to niak^, more fross-fmictional accept 
tance and coord inalion, and more diRlciiJty ctxirdinatiiig 
software and firmware developmen! uith hardware. 
As noted earlier, many of these perceplioiis are \'alid hat 
have extremely ad^'antageous cosi-beiient trade-offe. Since 
many software de\elopers are no longer prunar>^ users of 
their products, they now need to lie able to imderstand the 
primarv' users' nee<is. skill levels, aiid motl^'ations- Filially, 
m^jor changes in the castomer-developer relationship vm\ 
result ill customer demand for more input and iiTVOlvenieni 
in product definition and desigii. 

HP is continuously inipro\Tng the EVO process, building on 
our experience at different divisions. Tlie software inif iati\'e 
leanT now offers a workshop and consulting expertise on the 
EVO nieiho(i. Exjjerience with the value of using EVO to 
develop the infrasuijcture and the need for nianagenient 
focus have framed recent implementation effons. 

The key lessons to remember when first attempting EVO are 
to star*, sn^all, keep good records, and he diligent about 
doing the essentials. 



Acknowledgments 

T!ie auUior^ would like to tliank Mike Teska af Manufacturing 
Test Division for his support of software development 
method improvenient, the board consultant development 
team consisting of Sliaron LaTourrette, John McDemiid, Bob 
lUick, Kathy \Mlhers-Miklos, and Charles Zeng, and the users 
of The board consultant EVO releases. esj>ecially Kent 
Dinkel. We'd also like to thank Ttxid Con on and Beatrice 
Lam for discussing with us tlieir EX'O exj>eriences on some 
HP projects, and Tony Dicolen and other meml>ers of hi^ 
team at the Microwave Instrument Diilaon for sharing their 
EVO esperiences with ns. Finally, we'd like to thank the other 
development teanis within HP that have shared dieir EVO 
experiences with us and the softw^are initiative management 
for sponsoring this work. 

Reference 

1. T. Gilb, Prhtnptes ofStyfJwmT Engify^mng Management, 
Addison Wesley Publishing Company, 1988. 



AugtiftI U)90 I lewlcu- Packard JoiimitI 45 



)Copr. 1949-1998 Hewlett-Packard Co. 



HP Domain Analysis: Producing Useful 
Models for Reusable Software 



Early software reuse efforts focused on libraries of genera I -purpose 
routines or functions. These fine-grained assets did not produce the 
hoped-for quality and productivity improvements. Recent software reuse 
efforts have shown that architecture-based, domain-specific reuse can 
yield greater quality and productivity improvements. 

by Patricia Collins Cornwell 



A software domain is a set of systems or applications that 
share some common functionality. Tills common functional- 
ity is typically embodied in various software components.* 
Domain analysis is a software engineer mg process that pro- 
duces a characteriicaUon of a s<:>ftw£ne domain lo support the 
reuse of llie ^ofl ware components. The HP domain analysis 
methof J produces a set of models that guide the design of 
reusable software. 

Willie a few papers and books have been published on as- 
pects of domain analysis, ^'"'^^'*'' very httle has tieen puhlished 
on practical domain analysis methods. HP has developed 
and refilled a pracl.ic-a! domain analysis method which has 
been used in several reuse projects. The method has proven 
to be an effective and efficient way to get the information 
needed lor the design of domain-specific softw^are. The 
focus r>f eacli dcanain analy.sis is guided by the business 
priorities and anticifiated uses of the dojiiain models. 

TMs article describes a reuse process framework and the 
essential acti%4ties, deliverables, and typical uses of the re- 
sults from the HP domain analysis melhod. Because the HP 
domain analysis melhtxi is designed to be tailored to the 
strategies of HP's business organ i>;aliuns, sections of this 
article will describe the business context.s for reuse strate- 
gies and special reuse roles in the oiganixation. 

Reuse Process Fram^ework 

Early reuse eff<ii1s floe used on Jibiimes of general-purpose 
routines or functions. These small-grained assets did not 
produce the i>ro<iuctivity and quality improvements hoped 
for because so much engineering effort had to go uito mte- 
gi-atmg these assets to produce a useful product. More re- 
cent efforts have shown that architecture-based, domain- 
specific reuse witii larger assetj^ can provide significant 
productivity iuid quality improvements. For the past five 
years, praciical engineering exjDerience in adapting reuse to 
meet HP's business needs htis confirmed that the biggest 
return on investment comes from reuse that Ls based on 
domain -specific components that work m a flexible, hut 

' A compiere software component iritiluties both obj&ctcode amd all relai&d mformasmn needed 
to use ft This rBJaiBd irifarmaimn includes parafneterJzation information, sou(ce code i-f m\ 
praprietary, test infonnatjcm, design informaitDO, svaluatjon TBsuits, and other desctiptivs 



well -defined architecture. Reuse-oriented engineering ad- 
dresses how these software assets are produced, supported^ 
and used. 

Because each organization has its own variafions on pro- 
cesses and often quite distmct choices of sji ecific melhodSt 
the LIS, Department of Defense s Software Technology for 
Adaptable, Kehable Systems (STAIiS) program sponsored a 
project to develop a conceptual framework for reuse pro- 
cesses/^ This conceptual framework helps organizations 
nndersliind the relationships among their softw^ue asset 
produciion, supporln mtd utilization processes. HP partici- 
pated tieavily in the tiennitioii of the reuse process fi^ame- 
wijrk and provide<i sottie of the earliest experiences m its 
application. The useliilness of lliis reuse process was vali- 
dalefi with organizations adopting reuse-orierUed software 
engineering practices. This aiticle's discussion of ni^yor re- 
use processes blends the knowlefige gained from tlie STARS 
Conceptual Framework for Reuse Processes (CFTiP)^ witli 
subsequent experience in reuse adoption at HP. 

Fig. 1 sho>vfi the fundamental relationships among the reuse 
engmeering processes: produce iisset.s^ support assets, and 
utilize assets. AU three processes aie guided by the results 
of one or more doniaui analyses performed in the Analyze 
Domain process, which analyzes ancl models a dt>main for 
architecture-based, dommn-specific reuse efforts. Essentia] 
assets of softw aie reuse-oriented engineering include a 
tlomain architecture and reusable softwaie components.** 
Donuiin analysis produces domain models and other domain 
inform at i<jn itsed by the other three reuse-oriented engineer- 
ing processes. The domain modeis and information are valu- 
able assets, capturing the organization's kntjw ledge about its 
tJroduct line capabilities and how those capabiUties can work 
together in a range of competitive products. Fig. 2 shows a 
conceptual model for a data analysis domain, and Fig, S 
shows a physical envtionment model for a device measiu'e- 
ment domain. 

Domain analysis is an essential part of ajiy reuse effort. How- 
ever the domain analysis methods being used ui industry 
range from an Lnfomial and quick expert prediction of what 

' Sorr^E reusable JyOftware assets include snttware genemtofs rathsr than components that are 
based otii reusable code. 
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Fig. 1. Tlie donuiri analysis softwart* engineenng proci?ss. 



the doniain should cover to a MgWy stnictiired, exhaustive 
analysis m\d modeling effort witii hmidreds of pages of doc- 
umentation. For different business situations, eitlier of these 
extremes or more moderate alternatives may be appropriate. 
Across softwai'e engineering biLsinesses. il is not possible to 
define one domain tmalysis method that meets all needs. In 
fact, even the higher-level descriptions of an overall reuse 
process may differ sigruficaiH ly from organization to organi- 
jsatjon. Ilallver thati deriiiing a domain ;malysis metliod tliat 
Wfitild work in tmly one business romext, die HPiiomain 
analysis met hod is adaplable to a wide range of businesses 
rJiat generate products that include software or firmv^are. 



The Produce Assets process shown in Fig. ! uses domain 
models to develop reusable assets for use in poJtfoUos of 
products within the doinaiJi. The Support Assets process 
includes niaimging tlie collecrion of assets and assisting the 
users in understanding how to take best advantage of the 
assets. Asset support also includes senijig as a users' advo- 
cate wit)i producers, integrating the neecis of mimy user 
groups and assessing the relative benefits of prof lacing or 
reengineering part:iciilar assets. The Utiliice Assets process 
constructs new products with supported assets. 
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Fig. 2. noncfipLual model for 
a data analysrs domain. 



Au^usl i\m HewiettrPackanI .UwuvaI 47 



)Copr. 1949-1998 Hewlett-Packard Co. 



Custom HantwaFe 



Customer's Enterprise 
Cotnpijtii^g Environment 




Re'mo^te CantrQl 
and Data Shafiftg 



Iniiift/Oiitput 
Card 




Card Cage 



Fig. 3, Physical en^ironirtpnt 
[iLucicl fcir a device measuremeni: 

domain. 



Business Contexts for Reuse Strategies 

Tlie lli>5f step in any tlxnuain analysis Is i<> nihifrsiMiiM the 
business priorities anti cotislniiiits wlieie it'i jse is guii^g to 
be used. There are numerous business circuiustances that 
demand art improvement in the way software is developed 
and luaintaiiied. Reiise-oriented software eiigmeeruig is ofiten 
used to address business pressiues lor reducing pi cidiict 
cycle lime, increasing product quality, escalatuv^ llie tate 
of introduction of new product features, and improving 
employee job satisfaction- How^ever, software reuse is not 
always an appropriate way to accomplish business goals. 
Like so mai\v stjAware e (i gin ee ring me! hods , software reuse 
has become the goal for some organizations, rather than a 
means to accomphshing an organizaUon's busmess goals. To 
ensure that reust^ seives the business needs, we recommend 
thai tlie nmnagemenl of a reuse effoil hej*ni by explicitly 
jdentifying die business priorities tuid analyzing; what kind 
of reuse suategy (if any) will best support aclueving ihose 
prioiities. 

Some organizations Jiave latmclied reuse mitiatives only to 
find that their products do not lend themselves to produc- 
tive, cost-effective use of die software assets they develop. 
The two aspects of business context that most influence the 
decision to employ a reuse approac h are die biLsmess goals 
juid tiie product ])oitfoho chat act eristics. 

Businesses nee<l to be more productive than ever to be com- 
petitive. Softw^ai'e reuse is rai^ly a short-term solution for 
meeting these increased productivity pressures. However, 
with a managed hi vestment in adopting reuse, the benefits 
can be measured within die ftrst few uses of the softw are 
assets. 

Product Cvcle Ttme. In many commercial businesses, tlie 
strongest compel i tons aie those who rh"amatically reduce 
the time t)etueen introduction of a product and the intrch 
durtion oJ' its successor. To deteniune the potential impact 
of sofrwaie reiLse in meeting sliortened tuiie-to-niaiket goals, 
we fii^t assess whether software engineering ttlevelopment 
and quality assurance) has critical path activities for the 
overall product develppntent ami release process. Managers 



who are bemg encouraged to reduce product cycle time rwed 
to focus on engineering an ivities that pioduc^e more and do 
it faster^ possibly with a smaller team. Tliey cannot afford to 
make orgaiUKational or process changes to noncritical path 
efforts if those chatiges w^on't substantially improve the 
[nxjdutl rycle time. Adopring softwai'e reuse involves an 
tip-front investment in new^ skills and, oil en. m adthtional 
engineering effort. Tlierefore, investing m software reuse is 
apjiropriate when there is a predictable long-term benefit 
from the up-front investment, and tlie short -tenn costs of 
the investment iwt^ tolerable. 

Product Quality. To determine the potential impact of software 
reuse in meeting produt^t quality goals, we first assess how 
mucli of a product's quality is deterniined by the software or 
finn%vare. Software reuse is valuable in improving product 
quality wtten a signiHcant amount of the ftinrtionahtv' is con- 
sistent front profiuct to product, so that as that software is 
tested and i^n nse. more defects are foimd and fixed. For HP 
products, the question is often nut so much of ensming I he 
highest quality (w^hicb is a must) as it is of providing thai 
quality with less testing Ume, Nevertheless, as the reusable 
softwiu-e ''ages'* and fewer defects at^ found in successive 
uses, customers tend to experience higher quality in the 
prorlucis. 

Rate of Innovation. Many businesses make ongoing trade-offs 
betw^een the rate of introduction of new products and the 
number of innovations that £tre new to each successive 
product. The rate of innovation in i)roducts can be increased 
when I he produt t is based on a stable software idatfomi. 
A reusable software or finnware platform provides that base 
funcuonality without the effoit to design and implement the 
same functionality for each product, freeing the product 
team to focus on imiovations for each new iiroduct. 

Employee Job Satisfaction. Improved employee job ^tisfaction 
has become a very^ important business goal in some orgimi- 
zations. especially tJiose where intense pressures for meeting 
deadlines ha\ e resulted in employee burnout. We have 
w^orked with organ iisai ions where the n^ove to reiLse was 
motivated as nutch by Ute tlesue to provide a better work 
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environment for sustain^Ie employee job satisfaclion and 
work-life balance as it was to meet marketplac-e pre^ures. 
For an organization ihai already has ihe market share it 
needs and has a coiupetithe prfjduci !me. the goal niay be to 
release Uiose fuiitre pnxliicts %ntli a team that is energized by 
the software engineering efibn rather than exhausted by it. 

Note that software reuse often makes It imperative for an 

organization to adopt aj clulecture, design, implenwntation. 
and quahiy pnicUces thai wtmld t>e a sigruRcant benefit to 
their software engtneering projecis even if reuse were not 
acc:omplisl\ed. ^^lany software engineers welcome the mo%e 
to software engineering metliods that make them more pro- 
dnctave, which contributes to th€!ir job sadsfactioii. 

Frodiiot PortfohD CNaracterJstics, Mi increasing nmiiber of HP 
divisions have l>iLsiness plans for a portfolio of pi^oducts. 
The products may be tailored to address different market 
segments, from personal uses to enterprise uses, or tailored 
to meet specific uidustiy needs. Like automoti\-e or banking 
busmesses. We caii look at this portfoho as a snapshot-in- 
time of the set of products a business wants to dchver In 
addition, the product portfolio must be m^jiiagcd over time, 
with the introduction of additional featiu'cs in successix e 
versions of products. T\w businesses viiUagc ch^irt antici- 
pates the desired product e\"olution and provides essential 
rnfonnation for assessing tlie potential for reuse. 

The characteristics of a product portfoho that can improve 
tlie prospects for software reuse rely mostly on tlie stability 
of the featine set hi the product portfoho. There must hv 
some sigiiificant set of base functionality that tlie set of 
products have in conunon to nuike it profitable I o invest hi 
reuse. This conunon fimctjonality may const Uuie as little as 
10% of a product^s software and still be worth onplementhig 
witti reuse in mind. 

To reduc^e the risk of adopting reuse (any change involves 
risk, as does no chaiige), those c^hmteretl with producing the 
reusalfle software rely on access to experts in the kinds of 
fvinciionaiity for the products that will he tiroihiced. These 
people are often referred to as domain experts. Tliese ex- 
jjerts nuisl be made available to the domain analysis etTort 
as t>an of lu^magenumt sutiport tor tlie reuse siiatcg>; 

We nse a Rile of ttmmh ht which the asset designers must 
get access to at k^asl three existing examtdes of products 
that have the kind of fmictionality ihey w^uit to provide m a 
reusable form. They also need characterizations of at least 
three intended future prfiducts tliat w^ouid also have that 
kind of funct ioriality. Tlie three eximiples give concrete ui- 
fonuatioii ahont what functionality is common fan existence 
proof). The tbree projected uses suggest that the invest- 
ment will be amortized adet^uately to realize the benefits of 
designing, developing, and maintainuig the software assets, 
Tlie fudtre us<*s alscj suggest tlie i"ange of variation ttie assets 
must support, 

IIP Domain Analysis 

7'he MP duniain analysis fneihod was develoi>ed l>y HP's 
software initiative tsee i)age 42 j. Ttie HP domain analysis 
method supports analysis and modeling of capabilities 
(fiinctionaJity or servicesj provided by domains such as 
microwave frequency ineasuremeni niothiles, crn.sscorreia- 
don analysis algoritluns, or report generation routines. The 



method explicitly addresses gathering the constraiiits and 

requirements of producers, supporters, and anticipated 
users of the domain analysis and related assets. A reuse 
strategy" for software engineering is most successful when 
producers, supporters, and utilizers are fidl, active contribu- 
tors to the damairt analyses they will later use. Tlie roles of 
the i>roducers, supporters, and utilizers ane described in 
^ Reuse Roles" on page ~yiL 

Tlie Analyze Domain process shown in F1g> I produces a 
kind of reusable asset in the HP domain analysis meihod 
and is, therefore, conceptually a kind of Prmluce .'\ssets 
process. Nevertlieless, Rg. 1 shows the Analyse Domain 
process separately to em|)hasize that HP domahr analysis 
guides and Ls guided by all three fmidamentai reuse engi- 
neering processes. 

Basics of HP Domain Analysis 

Tlie HP doniaur iuialysis methoti includes domain analysis 
and modeling. Tlie analysis identifies capabilities of systems 
in a domahi of focus (1*^*, the set of systems being analyzed), 
and classifies the common capabilities atul tlie range of ^^ari- 
ation across systems that are anticipated in the future. The 
modeling captures the relationslups among critical capabili- 
ties in the domain and creates models of the capabilities and 
their relationships mthotit imposing a paiticul^ir implemen- 
tation solution. 

hi IIP domaui analysis, the term "domain" refers to any set 
of impiementations (systems or subsystems, for example) in 
which the iniplemerUaiioas Iiave some conmion capabilities. 
Most of the lime we liefme tlie domain by the sc^t of common 
cat laliili ties, ratlier than by listing all the potential implemen- 
tations tbat could fall in die domain. For example, for a do- 
main like a microwave measurement test syslem, there are 
endless possible products. However, most implementations 
of microwave measiuTmenl test systems include capabilides 
like test management, data management, report generation, 
signal measurement, and so on. 

There are no cf iminoti rtdes about wliat makes a set of capa- 
Ijilities die tight size and complexity to be caUed a domain. 
If the doniiiin of focus represents a consistent set of capabil- 
ities in a larger context (for exfmii>le, in the context of a 
liro<Jucl, (jottfcjlio), die most useful scope for such a tltjinain 
is otie ill wltich there is a high ch^gree of cohesiveness amt>ng 
the cat>alHlities wiUiin tiie di>maui, ami a limited coupling t.f ) 
other domaiits with wltich the domain of focus migfit be com- 
bined to produce products. For example, a tloniain like a 
graphics editor has significant complexity within ii. However, 
in a larger context like docum(?nt jmblishing, the grapliics 
editor might have connections to other domains like text 
editing and document printing, wltich have a well-^iefined 
and comparatively smiple interface. 

hitiiitively, domain assets ai e much more likely to be reusable 
if they pro\ide a coherent "chunk" of flesired catiabiljlies antl 
if the assets arc ea.sy to integrate inin a complete sohition. 
Typiciilly, ease of integration is atx'oinplislied witJi a simple 
mterfac*e between the assets anci the rest of tlie product 
software or flnnware- 
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Reuse Roles: Producers, Supporters, and Utilizers 



In the early stages of moving to reuse-Qnented product developmeni, 

software engineers take on the roles of being responsible for developing 
their software to be reusable (producersl, learning how to use software 
developed by others I utilizers), and supporting their software for use by 
others (supporters), As reuse becomes more systematic, it is common for 
organizations to evolve so that individuals take on the specific roles of 
producer, supporter or utilizer for the duration of a product development 
cycle. 

Fig. 1 shows the primary relationships among software engineering roles 
in a reuse-oriented organization, and the following sections describe the 
responsibilities for each of the roies. 

Domain Analyst 

• Analy^^e the common feature set and the range of feature van at ion 
across the projected uses of the assets. 

• Characterise capabilities the domain must provide to support the users 
of products buift with domain assets by the product developers, Capture 
the characterization in models that can be used to design and develop 
domain assets and guide the use of those assets, 

• Produce conceptual models that are readily understandable by managers, 
new project managers, and engineers who wilt produce, utilize, or support 
the domain assets. 

• Extract domain informalian from diverse sources such as past designs, 
interviews with experts, product data sheets, and trade press articles. 

• Use consistent, unambiguous termmology captured in the domain 
lexicon to communicate about the domain. 

• Develop and maintain a working partnership with producers, supporters, 
utilizers, managers, and key technical contributors. 

Producers 

• Include utilizers' requirements and needs as part of the design. Consider 
the utilizers' assessment of product requirements and what it tal<es for 
them to be able to tailor and integrate the assets easily to build products, 

• Include supporters' requirements and needs as part of the design 
Consider the supporters' ability to maintain the assets, to manage the 
asset base's evolution, and to provide assistance to utilizers. 

• Develop an architecture for the product portfolio that clearly defines the 
common elements and the range of variation across the uses of those 



elements. Design the architecture's evolution to meet de livery 
requirements. 

• Design the assets to support critical abilities like porta bifity, support- 
ability, extensibility, scalability, and tailorability and to meet functiorT' 

a lily and performance requirements. 

• Develop and maintain a working partnership with the domain anafysts, 
supporters, and utilizers, including managers and key technical 
contributors, 

Supporters 

• Develop and maintain a configuration management process and envi- 
ronment that support the producers and the various teams of utilizers, as 

well as making it easy to conhgure and distribute releases, 

• Provide asset use consulting to utilizers, 

• Join with producers throughout the producers' development effort to 
ensure that the assets will be easy to understand, maintain, and port, 

• Contribute to the prioritization of asset development and support ptans 
and consider the overall business priorities and needs, 

• Develop and maintain a working partnership with domain analysts, 
producers, utilizers, managers, and key technical contributors. 

Utilizer 

• Use the architecture and available software assets to guide every 
phase of the product development life cycte, This includes everything 

from determining product requirements to quality assurance, 

• Design the product to take advantage of new combinahons of features 
that could provide a market advantage, 

• Join with producers throughout the producer's devefopment effort to 
influence their design and implementation of assets so that they will 
meet the utilizer's product needs, 

• Join with the domain analyst to influence the scope of the domain and 
the domain utilizer's model 

9 Contribute to the prioritization of asset development and support 
plans, considering overall business priorities and needs. 

• Develop and maintain working partnerships with domain analysts, 
producers, supporters, managers, and key technical contributors. 
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Fig. 1. Relationships among the software 
engineering roles in a re use -oriented 
organEzation 
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The Method 

The HP domain aixalysis metliod usually involves tlu"ee 
cycles tlirough a set of well -defoied activities. Fig. 4 shows 
these activities and the deUverables they produce, and Fig. 5 
shows a t>pical level of effort expended on each dehveraljle 
during each of the thiee cycles thiough the domaiii analysis 
process. At each step through these cycles the analysis and 
models are refined and tieepened atul go rhiougli tlie same 
basic activities. The first cycle usually needs to focus on the 
context in which the domain will fujiction because the team 
is sU!l analyzit^g just what part of the overall product port- 
fr^lio rhe domain must cover The second and third cycles 




Fig. 4. The activities and deliver- 
ableii ihat make up rhe domaiii 
analysis processv 



refine the scope of the domain Eind fill in details on domain 
capabilities and their relationships. 

The following sections describe the activities shown in 
Pig, 4 mid the deUverables produced by eajch activity. 

Establish Domain Ana lysis Objectives. Use business goals and 
constrauits to produce a cleai statement of tJie purpose for 
tlie domain analysis. Identify those who have a stake in the 
domain analysis. lypicaJly stakeholders mciude managers in 
the product development organization, those who wiU design 
and implement: the domain assets, those who will support 
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Ob|ectiw«: The domain analysis will assets ^e valiii o| building products 
based on rousabie software, wftere Htot vaitiA is based on 
potential compeiiiive sdvanioge. 

Metrics: • Coitnl the number of competitive capabilitlos in the domatn 
capabiliry modots. 
t Name the cEusterB ot capabHFtiesttiat ntarkeling itfenlifie? 
as a dompetilive advantage. 

Objective: Determine what software would he highly reusable ss a 

software platform m out products targeted for the years 1397 
10 2001. 

Metrics: * Does the domain context mo if el clearly identTfy which parts 
of the domain constitute the plarform domain? 
* Does the platlarm domains canceptual mniiel capture the 
cafiabi lilies needed for tafgeted products in the years 1397 
to 20Dt? Are those capabilitios highly similar across the 
targeted products? 



Domain of Focus Stale me nt 

Tfie Rainbow domain [itoniain commoii name] i$ the system firmware that 
supports the set of all color printing solutions products [targeted products] 
anticipated in 1994 - 1997 {see Rainbow genealogy chartK iutilization time 
frame) There are three classes of end users lor the Rainbow riomarn: peopl^e 
wtiQ send print jabs in the printer to otitain printouts, third-party application 
developers of applications that have printing capabilities lie., applications 
that interface to Ramijow -compatible printer drivers], and the person who 
detects and reports pfoblems with the printer behavior, typically a systems 
administrator or product field service tecfinictan. ftargeind end usersj 

The Ram how domain supports people who send pfini jobs to the prirvter 
through Us ability to detect and report fto the appltcaiion from which the 
print request was made] any malfunctions and other status of the printer, to 
receive, interpret, and dispatch print commands (also, from tite application 
from which the print request was madel and to control the actual printing, 
paper handling, and front panel displays {if any|, {eKtenraNy observable 
capahilities] 



Fig, 6. All exaitifile ol' stjiiie tsf the ribjec Lives am;! nieirirs for a 
cioiTiL-iin Linciiysis project. 



Fig, 7, A lujrticiji of a dDmaiii-of-focus staiemetit far a printer 

cf.fnutiaiiil liajtiJiiiig doriiaiii. 



iJtObe assets, and tliowe wfio aie targeted to tililize liic assets. 
Get agreenieni fiont these people on the objectives. 

Hie deUverables from this activity include a statement of de- 
sired objectives for tliis domain analysis and a set of metrics 
that will detennine the progress and success of the analysis. 
The dtjcuinentation ^^ill also show how the dottiain dialysis 
objectives are aligned witli tlie business goals. Fig. show^s 
an example of some of the objectives and met rics for a do- 
main analysis project. 

"ITie value of this activity is that it ensures that the doniaui 
atialysis meets bitsiness needs, enables the domain analysis 
teant to niiiJiage its invest inent of tinu^ and effort , and estab- 
lishes a partnership with stakeholders to ensure that die 
domain analysis results meet their needs. 

Develop a Domain Context Model. Identiiy^ exaniples of existing 
systems 11 uU include capabihties of the doniam you have 
identiOed. I'se the list of targeted uses of the donuiin from 
the don^ain-oMociLs stateiiieu! to ideiUify exmnples t>f future 
systems that include the dotnaiii- Develop a top-level tnodel 
of the nisyor elements of the systems. Tliis is called the mega- 
do fnai a. Nomially this model contains five to eight elements, 
witti labeled relationsliips shown on the interconnections 
l>et weeu the elements. Fig. 2 shows a conceptual niotlel of a 
ntegadomaiJL 'Hi is mrxlel sen. es as the otgiuiization's domain 
context model, since the parts of the niegadomain that are 
in the doniaui-of-focus statement can be highiighfed at id the 
relationship to the overall megadotnaln can be identified. 

This activity identifies a top4evel uiterface between the 
doniahi atid the rest of a system. The focus of the activity is 
iti identitying what ]jarts of a system are within the doniam. 
The domain boundary' decision is refined over the three 
cycles of the domain analysis. 

Identify the Domain of Focus. Determine what domain will be 
the focus of the domain analysis and piXHiiice a ffottioithof- 
focus statement. Tlie domain-of-focus statement is a de- 
scriptive statement (about three to five pages long) of what 
characterizes the domain, in terms of its anticipated uses and 
the scope of its capabiUties. This statement complements 
the conceptual model (described below) and provides a 
basis for shared understanding about the domain, without 
needing to untierstand the det^iiled relationships of elements 



in the domain. Because it describes the scope of the domain, 
it guides tlie more detaileft modelitig efforts. Fig. 7 shows an 
exceriK ho in a doinain-of-focus stale nient for a printer com- 
mand handling dotuain. 

Be sure the tenninology used is dociuTiented ui the domain 
texicON (desciibed below). As the description of the domain 
evolves, be sure to keep the do main -of focus statement con- 
sistenf with the domain models, esijecially the cont. eptual 
model. Fig, 8 shows a portion of the lexicon for an I/O bus 
project. 



AccBSs Functifiiis: Functians that reail or write data within the ifortiain 
database. 

Arbitraifon Block; A software camponontthat monitors and controls 
arbilratian far a bus. 



ArbitFstton: The act of control ling access to a shared bus, 



Bus Driver The component that crnitrols a given set of signals on the bus, 
Nate that there h only one bus driver for a given set of signats. 

Bi^s Signal: This larm has two different meanings: hardware bus slgnai anij 
software bus signal A hardware bus signal is a voltage ar a wire tbat 
cotinects arcbitecture componants together, A software busaignal is a 
variable lb at models the hardware voltage on a wire, 



I/O Bus: The set of signals neeited for ccMnntifnication between I/O ifevices 
and the processor bus. 

I/D Conlioller: Hardware or HDL model that handles elf I/O transfms from the 
processor bus to the I/O bus. 



Processor Bus: The set of signals needed for communication between 
{irtjce^ars^ I/O contrallers, and memory. 



Transaction: A series of events on a bus that accomplish a certain task. 
A transaction transfers data, inquires abaut or change state, or provides the 
system with information. 



Fig. 8. All example of definltiuBs iJiat rtiight appear in a domain 
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This activity provides a succinct statement of the essential 
characteristics of tlie domain for use with stakeholders, h 
also ser\ es as a reference for decisions about tlie scope of 
the dotnaiii. 

Gather Domain lirformation. Look at existing s^i^ems that in- 
clude liw tloniani. .\iso look at infomtation on future prod- 
ucls thai might be able to use reusable designs and imple- 
mentaiions in the same domain. Interview domain experts 
for their knowledge about treiicis in leehnolog>^ or capal>ih- 
ties assoctaied with the domain. Identify the externally 
obsenaijle (apal>iUties tif the domain. 

This acthity provides the technical information for analyzing 
ajid modeling the domain, and ensures that the domain char- 
act eriziititjii is accurate and adequately complete. 

Develop a Coitceptual Modal. Create a graphical depiction of 
iht' (iiniiairi's ()iiiiian elements ajid tlieir rt^lationships. This 
mot lei tBay not be a tecimically atturatf. ro])-le\'el represen- 
tation t)f Uie eventual design, but rather is an easy way to 
Uiiderstand the "big pictiu-e" of tlie domain. It complements 
the domain-of-focus statement. Often the domain-of-foeus 
statement and the conceptual model mv used in maiiage- 
mem IjriefLngs and as part of the support documentation for 
engineers who need a general understanding of tiie domaki. 

Tliere is no need to be fancy with the conceptual model. In 
fact, an intuitive model is preferred. Arc^s between elentents 
of the nitxlel must be labeled and riie intendeil inteipreiation 
of the connections between those elements miLst be docu- 
mented. The conceptual model should use die reniiinnlogj^ 
defined in the lexicon and must be consistent with the 
domain description in the domain-of-focus statement. 
Usability uf Ihv conc^eptual model is enluuiced by using a 
single mtjdeling paratligm such as process flow, data flow, 
or entity-relationship diagrams. 

Define the Domain Lexicon. This is an ougoing ailivity in which 
terras nsvd ii> dist uss the domain Eiredefitu^d, with pointers 
to related tenus. T\\e- lexicon ts used as a referen<'e docu- 
ment for the terminology of choice for eomuHinirating about 
tiie (iojuain. The tiomain lexicon uttiiides every term iri the 
fiomain motiels. It is invaluable in saving dine iuid mhiimissit^g 
misunderstandings among the asset producers or between 
jLHset pnKhireis, suppoiteis, and utilizets be<*ause il enablej^ 
dieni id in1(Mi>rel the domahi tncKlels conwistenlly. Tlie tln- 
n^ain lexicon aiso allows a new niemiier of a lemn to study 
the domaitt models and gain an initial understanding of tiie 
models witiiout needing full-time assistaiice. 

Tills effort will create a common iiiulerstanding of concepts 
related to the domain, capinre det isions al>oui i^refeni-d 
terminologyp and suppi:irt efilcient learning about the domain. 

Model Domain Capabihties. Develop a model or set of models 
thai ( jipiiin' ilu^ relat ionships among externally observal>le 
capabilities of the domain. This model is based on the gath- 
ered df>main infonnation, uses the tejininology tjf the lexic'on, 
iind Iscoiisififi'ti! witli Ihedomain-t^f-focusslalemeni and 
the eonee|jtnal nntrkH. The eapiihihlies nun lei is the primaiy 
referem'e used by the domain ar tiiiteci and asset designers, 
Thus» it must contain a characterization of all essential, ex- 
tern^tlly olihserv^able capabilities of the domain. Also. l>ecause 
the capatnhlies model is coiirerncd witli ihe t^vlernally 
observable (capabilities of tlie dotitain, it can bt* a valuable 



dDCuznent for those needing to understand how to maintain 
or use the domairu 

Later the arthiiecture and designers (who are members of 
the producer team) i%ill transform the cai>abilities inrwiel 
into a chosen engineering solution. For organizations that 
tiave not done fomtal architecture and design, the t^pabiii* 
tJ€^ model may serve as the design, supplemented by the 
other domain mcHiels. As the organization s skill in software 
design increases, the eapabiliiies motiel will be the pritiuuy 
source of information for guiding tiie more detailed and for- 
mal software design. The domain analyst documents links 
between gathered domain information and detrlsions about 
capabilities and their relationships, 

Tlte mos! pi-actical approach to capabilities modehng is to 
use iJie same i>*ij^**itgtn as villi be used in the arcliilet^nu-e and 
design of the tlomain assets. Feature-based mcjdels, entity- 
relationship-attribute tnodels. object-sei^ices models, and 
logic-rules models can be eniptt)yed. However, the domaiji 
models are tif>t meant to reflect inipleruejiiation decisions. 
Fuitbennore. the capiil)iJities models show only what is ob- 
sen^able to utilizers and end iisevs of the domain capabihties. 

Most capabilities modeling requires a combination of aggre- 
gation, abstraction, and decomposition ^ijiproaches to idetitify 
the top two or three layeiis of externally observ'able capabili- 
ties. Since these layei's may not be siric lly hieriOfhicaK the 
models nntsl capture the kinds of relat ionship.s thai eKisi 
among the capabilities, (. apability nu^dels idet\lily each of 
ti\e capabilities as retiuired, or oi)tioiially, identify sets of 
alteniative capabUities and note father capability inter- 
dependencies. 

The nujst Israel iiu I way Itv ca[)ture the range «>f variation 
across intended uses nf tiie flumain is thriHigb tise scenmios. 
One vei^ useful kinti of model shows stinuilus-response 
relationsliips muong capabilities (le., what services or 
actions tnuispire as a result of what events) for different 
scenarios. 

Modeling the domaui ca[>abihties provides dfju^ain art*hilects 
an(i asst^t designers with a chai-acteriziitioji tif the ilouuun's 
externally observ^abie capabilities m sufficient detail for 
lU'ehitertiu'e mid external design needs. 

Model Physical Environments. Characterize the physical envi- 
roiunents in whieh I lie s<vftware for the domain needs to 
work, Thi.s may mean describin|Jj Ihc^ processors in an uistru- 
ment where linnwju^e ruis, or tlte vatious lieterogeneous 
enterprise environments where application software will 
run. Also, if there are tli verse interface standards to be met, 
those aie captur*'d in this model Fig. 3 shows im ex^unple of 
a simplifiett jjhysical environment context mtKlel, 

Tills acti\ ity ensures that asset designei^s hav-e the informa- 
tion needed to acconunodate computing environment con- 
straints, like pju'alle] or distributed jn'<jcessing, and refines 
liie S( ope of the intetuled use of the dimiain assets. 

Model End Users' Needs, t'apture the characteristics of the 
end users that euuld itilluence the design or the implementa- 
tion oTdumain assets Bach targeted develo[imeiit project 
may provltk^ u eliarai'tenzation of their end users that in- 
chules skill level, un tiers tan ding of how the product worksj 
expedatjons. and a menial model of the user jinetfa(*e. The 
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Management 

Successful reuse depends on a different kind of relaiicnship among engi- 
neering teams, The teems behave as true partners, each concerned for 
and respectful of the legitimate needs and constraints of the other Be- 
cause this partnership ts so critical to successful reuse, managers whose 
responsibilities span the producer and utilizer organizations need to 
understand the issues involved, support the reuse effort with computing 
and training resources, allow time for regular communication and joint 
decision-making by producers and utilizers, and acknowledge the value 
of the reuse investment. 

This is no easy task when the next produces release is in danger of slip- 
ping and the return on the reuse investment will not be felt until products 
after the current product are in development Nevertheless, without 
informed senior management involvement and support, producer and 
utilizer organizations find it difficult to behave as true partners, and typi- 
cal ty fall back into the old ways of engineering software, which are the 
very ways they had decided to abandon because they would not meet 
future business needs. 

In one HP organization, a lab manager endorsed a pilot reuse project for 
reengineering existing software into a more easily reused software plat- 
form. The [ab manager^s responsibilities spanned the platform engineer- 
ing team and numerous product development teams that would use the 
platform, The lab manager^s leadership and active involvement in under- 
standing the issues, providing resources, and rewardmg reusable results 
transformed the way software and hrmware components for an enhre 
product line were produced. The transformation did not take place over- 
nlght. However, the business is now producing four to six products per 
year rather than the one per year that \\ was producing four years ago 
when the reuse effort began. This has been accomplished with a modest 
increase in staffing and a great deal of software and firmware reuse or 
leverage. 

In another business sector, a group of businesses agreed to cooperate on 
the development of a reusable software platform that could be used in 
numerous product lines. The senior management (R&D group managers! 
invested in the project and encouraged the individual businesses to invest 
senior technical contributors in the asset production effort, These senior 
technical contributors served as producers m the early months of the 
reuse effort. However, they were also responsible for representing the 
needs of their individual organizations as potential utilizers of the soft- 
ware platform. As a serendipitous result, the resulting platform was 
used to bootstrap a new business that had many of the same product 
capabilities that had been analysed and designed into the reusable soft- 
ware, allowing HP to get to market substantially faster with a highly 
competitive product. 

Unfortunately, there are also examples where talented engineers have 
developed solid technrcal solutions for reuse, but were unable to engage 
their targeted utilizers or were unable to get senior management involve- 
ment and active support. Eventual iy. each of these investments was 
abandoned with a return to the short-term product development methods 
that were not meeting business needs when the reuse effort began. 
There is a very strong correlation between engaging producers, utilizers. 
and managers and succeeding with reuse. 



models of end users trsmsiat^ the end-users* usability require- 
ments iiitf) a model of tlie capabilities the domain provides 
to meet those reqniiements. 

This activity ensures end-user usability of domain assets and 
often influences the set of capabilities provided. 

Model Utilizer Needs. Use identified utilizer needs for usabil- 
ity of the dumain assets. This list usually includes the utiliz- 
er's constraints with respect to development euvironnienl 
(programming tools, version control and configuration man- 
agement expectations, etc.). usage suppoit retiuirements, 
aitd skiU levf I This uifonnation may influence the reusability 
requirement decisions and ttie domain arcluLecLure or asset 
design. The utihzer model translates the utilizers usability 
requirements mto a model of the capabihties the domain's 
components pro\ide to meet those requirements. This model 
is typically quite different from the end-user model because 
it shows what will need to be pro\ided in the product devel- 
opment phase» rather than the functionality needed in the 
delivered product, 

ReusabiHty Requirements. Develop a clear state mem of how 
the domain will interpret such reusability rhai'act eristics as 
portability, modularity, scalability, extensibility tailorability, 
interoperability; plug compatibility and standards confor- 
mance. This statement defines how the team wiU know 
when they have achieved adequate reusability in their 
domain design and implementation. 

Validate Models. Ensure consistency completeness, and 
usability of the domain analysis tmd models. This activity is 
best supported with regular anti explicit (Quality assurance 
acti\ities, like miuire views or checkoffs against objectives 
and measures defined in establishing domain aivalysis objec- 
tives. This acd\it>' will ensure quality and provide an assess- 
ment of when the domain analysis is adequately complete. 

How Much *^ 

The knowledge captm-ed diuinj* a domain analysis is essen- 
tial for success in reuse. Therefore, tlonialn analysis is not 
overhead but rather a low-risk, efllcient way of gathering 
and developing domam knowledge in forms that are readily 
accessible to those in the orgaj^ization who: 

• Develop reusable soflwai'e or firmware 

• Develop products that use die reusable assets 

• Support the assets. 

Tlie larger the domain, the more people ai^e typically involved 
in the domain analysis. Nevertheless, planning for it to take 
about six weeks of full-time elTori frojn the start of the anal- 
ysis and modeling until the stakeholdeis have what they 
need to delve itito architecture aiul asset design is reason- 
able. Nomially, the stakeholders are the first people to use 
the domain analysis results. For a team new to domain 
analysis, productivity will be gieatly enlianced by iia\4ng an 
experienced domain analyst (even one from a very different 
domain) available to guide the team through the method. 

As mentioned earlier, the HP doniaiti analysis metbod has 
tliree cycles of well-defined activities. For a typical domain, 
the first cycle generally takes about a week of focused effort 
for the domain analyst, who is leadmg the dOEuain analysis 
elloit, plus 10 to SO hours for each of the domain experts 
providing tnformaTion and assisting in the cUialysis. The sec- 
ond cycle takes about two weeks of information gatheiing, 
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anal^'sis^ and modeMng for the doinain analyst and those 
who will be involved in the design and implementation of 
the domain assets. The users are consulted during this cycle, 
but the time commitment may only need to be a few hours 
for review and suggesTions. The final cycle takes at)out three 
w'eeks for refining and validanng the anal>'5is and models. 
The domain analj'st is involved full time. w*hile the domain 
architect and domain asset designers ntay begin sketching 
out their first asset design ideas in parallel with the third 
domain analj^is cycle. This parallel approach can ensure 
that the refining and validating acti%1ties meet the designers' 
needs. Domain analysis typically ends as an explicit acti\ity 
when the design team has the inforrrtation it needs to de- 
velop or reengineer an architecture and reusable software. 
However, it is important to maintain consistency betw-een 
reciuirements, domain models, domain arcJiitecture, and 
asset desigjT. 

Using HP Domain Analysts Results 

Tlie deliverables from an HP domain analysis are designed to 
be useful in other specific rtnise activities, bi architerting the 
domain and designing the reusable assets ( l^oduce Assets m 
Hg. 1 ), all of the deliverables are used. The capabilit>^ models 
and domain characterizations are primarily targeted to be 
used to guide these activities. 

In supporting asset utilization, the lexicon is indispensable. 
The conceptual model and domain-of-foctas statement are 
especially useful in acquainting de\'elopers with the dnniain 
assets (a fomi of asset support). The rai:»ahility nnxiels and 
domain chamcterizations provide useful details for the uti- 
lizer, who is ti^g to tmderstand how the assets might best 
provide the capabilities needed In the product (another form 
of asset support), Tlie lexicon and capahiliry model also 
suppon asset managt^nienl through libraiy cliissification, 
asset access, and connguration management. 

In using assets, tJie utilizer will likely reference most of the 
domain analysis deliverables, initially relying on the con- 
ceptual nioflet and dou^ain-of-focus statement. Part of using 
assets is taking the initiative to identily assel requirements 
to ttie producers, whff will translate rcciuiremtmts requests 
into refinenietUs of the impacted deliverables. For example, 
the need for a rtew capability is reflected in the capabilit.v 
models and lexicon. 

Generally, uianagers rely most heavily on the conceptual 
mode! and domain-of-focus statement, with the lexicon as 
background materia!. 



Conclnsioii 

The HP domain analysis method prmides a simple and effec- 
ti\'e way of getting information needed to be successful in 
domain-specific, architecture-based reuse. By providing a 
method with a dear set of deliv erables that have well-defined 
uses, we improve the efficiencv' and effectiveness of the 
domain analysis. Following the HP domain analysis method 
can subsiajitially reduce the rbks in reuseoriented software 
engineering, risks that arise when tiie assets produced and 
supported do not adequately meet utilizers' or end-users* 
needs. 

In most cases, we find the best results are obtained working 
with an experienced domain anal,vsi the first time a team 
goes through the cycles to do their first domain analysis. 
Over time, that team's experience in domain analysis can 
increase lo a level of domain analysis expertise that can be 
spread throughout the organization. 

Ac kno wiedgm en ts 

The HP ciomaiu analysis method was initially captured as a 
domain analysis workbook. Its primaiy author was Mark 
Sinios of Organon Motives, who w^as a consuJtant to HPs 
softw'are initiative prograi^t. Modifications to the w^orkbook 
and the luulerlying process model w^ere influenced by the 
work of Ruben Prieto-Dia^ and Guillemio .-Krango,'*'^ A com- 
pletely new^ workbook was developed after the modified 
w^orkbook was used with HP product develop nteitt teams In 
the computer peripherals, computer systems, medical, and 
test and measurement hus in esses. Mike Ogusli and Tom Van 
Slack from the sohivare inifiative program fvave provided 
valuable suggestions for making the method match the needs 
of HP software development organizations. 
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A Model for Platform Development 



For many software and firmware products today, creating the entire 
architecture and design and all the software modules from the ground up 
is no longer feasible, especially from the point of view of product quality, 
ease of implementation, and short product development schedules. 
Therefore, the trend is to create new product versions by intentionally 
reusing the architecture, design, and code from an established software 
platform. 

by Emil Jandourek 



HFs software initiative program lia.s been working io part- 
nership wUh produci developnier^t orgatii/Jitions in Hewlett^ 
Packard for alniosi fhe years. Ir.s goal is lo help rake soft- 
ware and nrmware developrneni off the critioai path of new 
product introductions and transform HP's software and 
firmware development capability into a competitive advan- 
tage. Through oin^ work we have observed 3L\\i\ ]>aitiripated 
in the application of many different strategies, all aimed at 
raising an R&D team's collective abilit>' t(i build sQftw^m"e 
and finnw^aie that meets the overall mm ket require men is, 
including functionality, usability, reliability, perfomiance, 
suppoitabllily, and tirne-to-market goals. 

Several pattenis have emerged that mmiy tIP organizations 
ai'c successfully usmg to elevate tlicir software and firm- 
ware development capabilitj'. One pattern corresponds lo a 
set of operational practices that wc call the platfonn dftvfd- 
opmeni paradigm. The software initiative program has 
created a conceptual mo(iel for ptatfomi development (see 



Fig. 1) which builds upon HP s product development ex}>eri- 
ence and integrates many of HP's best practices in soft w^are 
development. The individual elements of the model ai*e 
closely tied to the technical and management systems used 
in the company and have been validated through actual team 
experiences in develoi)ing new products. 

Since the platform development model is conceptual, it is 
iLsed as a framew^ork for deteniiining tlie elemeuis that ari 
organization needs to invest in lo altairi a competetM'y in 
platform developmenh Tlie soflwaie initiative program works 
with prcKluct development organisations to identify tiie meas 
of the model that are appU cable to a given organization's 
situation and works with the (ugmiization to customize the 
model accordingly. The resulting instantiation of the model 
yields processes tuned to the specific needs and requirements 
of the particular development organization, leading to a new 
level of development capability. Organizations within IIP 
tJiat have established a competency in platfonn development 
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Fig. 1. Major elements of Lite 
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have si^ftcanUy reduced their time to market, improved 

ofx^rational elTiciene>% and become more respoasive to the 
tiee<ls of tlieir custoniers. These gains are ac-cooii>anJed by 
iniproved business results. 

The following are brief descriptioas of the elements of the 

platform development model shown in Fig, 1. 

• Product Portfolio Planning. TTiis element defines the strategic 
relationship between the platfomi and aU product versions 
to be released over a niultiyear period. It identifies the key 
business drivers and sels the o\ erall goals, direction, priori- 
ties, and partuneters of the platform strategy'. 

• .\rchitecttire. This group of elements includes: 

t Arehiteetural definition and partitioning of the mBUor 
functional and letltnology subsystems, 

z Product feature mapping, which identifies appropriate 
subsystems and conipoiipni modules used in the imple- 
mentation of each feature ti.e., translatioti of customer 
needs to product features to specific plaifonn or proclut t 
modules) 

: Test arfrhitectiu-e and strategy, which define tiie overall 
structure ai\fl methods for verification and validation to 
ensure necessai>' quality levels in the final prf)duct,. 
■ Platform Management. This group of elements includes: 

: Organizational structure and work partitioning, which 
defines the organization s operating model at an abstract 
level (e.g., reporting relationships and team organization) 

o Partnership model and contract, which provides the 
generic framework for instantiadng the operating model 
between platform and product teams {e.g.. interdepen- 
dence l>etw^een teams and exjjectations for their working 
relationships) 

o Managernerit processes ;md steering teaiTis, which define 
how the j>ro(hi<1 portfolio plan iscreafeii and how its 
execution is managed 

c Communication and feedback rncuiel, whicli defines the 
timing Jiiid conteni of the infomiation thai fiows between 
teams. 

• Developnienf . This group of elements includes: 

o Platfonnand protliui lift^ cycles, wliich define the miyor 
phases, with goals, activities, and deliverables for both the 
I)la1lonn ami products 

c Devclojnneni irUKlel and process, which specify tlie pro- 
cess<\s folio wed fr*!^ die ereatii^n and enhancetuenl of a 
module through its inn^gration into the Onal fjniducl 

o Delivery model which defines how platform components 
and subsystems are delivered for use widun t^roducts 

o Validation and test [vrot tosses, which defitie the spetine 
quality ct iteria luui test procedures used Qirougtiout the 
product and platform life cycles 

o Developmei^t tools and infrastnuntre. which provide a 
common develotmieni iMivironment mid j>rocesses for 
platfomi and i.troducl work (e.g.. i.iroi'edures and tools 
for creating^ storing, fituhng, building, and testing 
components). 

• Stippori Model Tliis elenictu defines the mechanics and 
logistics of how iu<iividNais 'dnd teams gel help when using 
plat f< ) rn I c omponents . 

• M*^fri<.s m\(\ MetLsurenient Prf»cesses, This element defines 
the means by which jircjgress atui results for i^ach of tlie 
other eli^nejrls are monitored to ensure achievement of 
latsiness gi>als. 



* Values and Reward SystenL This element integrates and 

ahgns the organization's values and culture with its perfor- 
mance e\'aJuation and reward mechanisms to support the 
other elements of the motlel and thereby arliie%'e platform, 
product^ and business goals. 

The remainder of this article describes the key elements of 
the moflel in greater detail including the deployment and 
use of the elements, anecdotes about llieLr implementation, 
and finally, HP s experiences witli the model The iLSe of the 
word "software" tliroughout tliis article refers to both soft- 
ware and firmware. 

Definitions and Background 

For HP *md mm\v (jfiier high-iecluiology businesses, the 
evoiulitm of product development organizations parallels 
that of a company s business. The character of a business 
changes as its products evolve, mature, iind expand their 
miirket penetration beyond the mnovalors atwl early adopters. 

This technology adoption life cycle has impUc^ations for bow 
an organization develops its products.^ An orgimization's first 
product for a new, emerging market is often an experiment 
aimed at validating a product concept and gettuig feedback 
to help shape its evolution. Consequently, the first product is 
often incomplete and may in faei be acleaned-u|» prototype. 
Successful market introduction and subsequent demand for 
the product inevitably lead to plans for foilow-on products. 

Paradigm I: Serial Development Projects 

EJevelopment during the early stage of a new product s life 
cycle is characterized by a series of independent projects 
(see Fig. 2). A "just build it" mentality oft.eti drives the first 
few products l>ecause of uncertainty about the nutrkei ac- 
ceptance of the product. F'rom a software fieveloi>ment t>er- 
spective, the product's tuchitectun* and design are ofien 
implicit and poorly documented. Little st nict.ure and fomial- 
ity work reasonal>ly well fur small development teams as 
long its there is contitmity between the iiiiifal pro<luct te^un 
and the teams that develop subsequent products. In fact, 
very often the initial team and the teams for follow-on prod- 
ucts fire the sam(\ Tliis continuity of indi\idtials and teams 
enables both flesigri and c^fMie leverage betwt^en projects. 

hi p;iradigm I tlie tune to market (TTM) is defined as the 
tinu' between 1 be start or itiitial staffing (tf the pioje^i and 
Its release to customers. Organi/.ational Ictmiiiig and k^verage 
between any two sttecessive projects can reduce the TTM 
for the latter (irojeet. Thus, if a similar muounl of fiuirtional- 
ity is containt^d in both projet ts *)ne expet-ts the TI'M (t>v 
project N + 1 lo be less than the TTM for project N\ Ideally, 
ttie bulk of the effon invested in a latter (>roject is din*cted 
at those value-added differentiating features that ;ire \isible 
to customers. 

An orgariizatirm cm\ choose any number of different devel 
opmeru methodologies or life cycles Uw its di^velopment 
effort. Within IIP, many organizations are adopting an t^vohi- 
lionaty delivery approach as ojiposed to a waterfall tuodel 
(see the articles on [>ages 3Si and 25 atul reference 2), In fact, 
(*ven those using a waliTfall n^todel have nn>dified it to sup- 
l>ort jjtcreased eoneurrency and redtire the impact of a reset 
at any stage. 
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Every Project ts the First Project 

Characteristics: 

« Serial Development 

• PfoJBct Independence 

• "Just Build It' Philosophv 

• Design Is Implicit 

« Design U nqt Necessarily Documanted 

• Lots af Leverage 

• Same Teani 
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P| = Drfferent Products in the Same Product Line 

S = Start of Project 

I/L = Tfansrtron Checkpomt frem Investigation to Development 

M/H = Menufactiiring Release 

TTM = Time tn Market 

TBSP = Time Between Successive Products 



Fig. 2. Paradigm f, serial develop- 
ment projects. 



The time between successive products (TBSP) is calculated 
by subtracting tlie release date of the earliei* product froiu 
that of the later product. Tlus measure is referred to as time 
to niaiket prime ('ITM") by some organizations. In the case 
of serial indeperiileul projects TBSP is equivalent to the TTM 
of the last prod 1 in. 

Paradigm II: Multiple Parallel Projects 

When a business finds increased market accept^ance of its 
prodtirts and has market penetration beyond the innovators 
and early adopters, it is common for customers to demand 
follow-on products with shorter internals betwee]i them. 
The pressure to do faster product releases and thereby cut 
TBSP almost invariably resulti^ in a shift witliin the product 
development organization to mniti]>Ie independent projects. 
We call this paradigm II (see Fig. 3). This situation usually 
results in differ eitt teams working m parallel to build closely 
related jjroducts. 

In paradigm II the TTM does not necessatily change, hut 
the TBSP shrinks hecatise of the overlap benveen projects. 
Customer demands for frequent product releases and con- 
sistency ^^ it bin a product family pi it pressure on the product 
de^^el opulent organization to achie\'e aii appi opiiate level of 
consistency across products and shiink both TTM antl TBSR 
The potential to reduce the TTM for follow-on products 
exists if there is a high degree of leverage from preiloiis 
products. Since leverage fundtunentaUy looks into the past 
for existing assets to draw upon, there is no guarantee that 
the softw^are foun<:l will not require require extensive modifi- 
cations to work for the new producl. Tims, the benefit of 
Ie\erage is subject to an inherent hmitation and in the i^^orst 
case may be negative (I.e., when the cost of leverage exceeds 
that of a new implementation). 



A much greatei' reduction in TTM can be achieved if exten- 
sive reuse is possible. Reuse fundamentally looks to the 
future and orients development Euouiid what follow-on 
products will require. Since reusable software components 
are designed witti tlte future in mind, they can be plugged 
into t\ew iiroditcts without tuiy modifications. This is known 
as black-box reuse because ihe component user s pritu^iry 
concern is with the external hehavior atul interfaces and not 
^ath the interna] details of the component. The practices of 
leverage and reuse form two ends of a continuimi iri terms 
of benefit to recipient project teams. In general, tlie hettefits 
for project teams that reuse components aie greater than 
those tJiat le\ erage c timptments. However, components that 
are not specifically designed for reuse typically need to be 
modified and hence end up being leveraged. There are sig- 
niftcaiu differences in lfie development processes used to 
build reusable components. 

The challerige for organizations doing multi]ile independent 
but related projects in parallel is to make the practices of 
leverage and reuse happen predictably across projects. These 
practices can happen at multiple levels, from the sharing of 
architecture and high-level designs to ot>ject code and test 
vectoi-s. Tl^e larger the granui^irity of work shared, the greater 
the impact on reducing project TTM. For example, reiusing a 
complete en'or-handiing subsystem will reduce project effort 
more than reusing just a few selected error liandlirtg joutines. 

In paiadigm 11, individual teants usually ha\e dedicated 
project managers and architects for each product. This con- 
figmation provides each team with a large degree of inde- 
pendence and autonomy. At the same time it can also make 
it difficult to coordinate the sharing of work between tetmis. 
Many organizations find that their predominant mode of 
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Cliargcieri^lics: 

• Parallel Development 

• Project Independence 
« Ucal Optimisation 

• Products LoDk Simiiaf 

• design Is Probably not Explicrt 

• Oiffereni Teams, Some Leverage 

• Architecture Benefits Acanre to 
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Challenge: 

• Make leverage or reuse of botli design and cacte 
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operation closely follows paradigm IL For businesses with 
(iiffereni prodiici lines there may be seveml sets of indepen- 
lietH projet^ts tmdenvay at aiiy given time. 

Paradigm III: Plat for ni Developiiient 

Businesses thai ha\-e fimily established a presence for their 
piodLicts in the mr;tjket|>lace, have nitniMJ hryond Ihe early 
adopters, and havt^ achieveti a det^p ctislidm-r and product 
understiUiding may cfmsider moviiij* to platform develop- 
meni, paradigm III (spe Fig. 4). PlaJftirm developtnent is 
essetifially lui extension nf paradigm II, where the common 
elements within a product family are factored out and devt*!- 
opcd once. The essence of paradigm III is to pull out those 
product elements, teatiires, and subsystems that are stable 
jiiid well-tmderstood, and that proiide a basis for value- 
added, differentiating features. 

A plaifomt is different froni a reuse library in that it has a 
cohesive, underlying archhecfiire. The exact cotni>osition of 
the platform for any given product family (^an range from a 
complete product framework to a collection of sut>sys terns 
to sets of indivichiat components. Tire platfomrs contribu- 
tion to ijidi\idnal products can var^^ from KM ic:) nearly 9(]fM\, 
either in terms of code or devi^lopment effort . llie exact 
amount and form of the contribution depend on Ihe specific 
ni^eds of each prtJckKt family. Products tlcneloped using the 
feattir(^s mid per\^asive structures (e.g-. error handlittg and 
GUI stajidards) resident within the platform have a much 
shorter TTM. 

Tiie shift to platform developntent takes the effort, an orgaiu- 
zation normally puts into product basics iind redtices it 
tlirotigh tTnse, j\llhotigli m-w functionality and fi^anjies can 
be provided by i^itherplalfonn or jiroducl software, in casps 
involving a hu^g*^ degree of ttncertaitity ttew feattiri's are 
usually imtJlemented iis pari of the product Once the new 



P, ±^ Different Pro duels in tlie Same Product Line 

$ = Start of Project 

t/l = Traitsition Checkpoiut from Invasitgatjon to Development 

M/R ^ Vlanulacturmg Release 

TtM = Time to Market 

TBSP = TTme Between Successive Products 



Fig. 3, Partttligtii II. multiple 
paralle! projects* 

product functionality stabilizes and is accepted by the 
market pi are, it can be tnigrated into the plafform. TI^us, it 
becomes available to subsequent product development 
efforts. 

Ttie net resull of iinplementir^g paradigm 10 is a reduction in 
t tie TTM for individual |>rr>jects. This reduction roupletl with 
the parallel flevelopment Itiherent in paradigm 11 allows 
orgiuiizations to shrink their TBvSF^ This also enables belter 
market resixmsivetiess. ancJ not sttrt>risingly* iti mature taisi' 
nesses a wholi> series of platfonns may be developed to sup- 
pon differenj pixMluct families. 

Examples 

Thr foi lowing two e.vamples seive to illustrate tht^ power of 
platform (development. In the consumer electronics w*orld, 
Sony Kleftirmic^s lnc^ is a ltU"ge producer of handhekl porta- 
ble, radio and cassette players. In fact, Sony makes over 
t%venty diffen^nt Walkman " stereo radio and cassette players 
that it sells itt tiie 1 inited States. Close examination of these 
luoducts reveals tlial only a few^ underlying cassette mecha- 
nisms huH cuM^^ nre used for the entire product fiunily. These 
iTier}i;iiiisiii^ ;riid [lackagmg constitute Sonys platfonus, and 
1 1 1- \ ^ I : 1 1 ih Sum V f o generate an assortment of products 
kit -^1 hi I til a lucuitl spectnmi of customer needs extremely 
lapji tlv The incremental ui vestment needed for Sony to bring 
uui a new tufjdel is small because of the large amount of 
reitsi^ offered through its platforms. There are numerous 
other examples like this in the consumer electronics markets. 

Within tiie computer networking nuu*ket, HP offers a product 
called IIP (JpenView, a software product used for mimaging 
complex networks. In MP Open Views case, [larls of the soft- 
wan^ form a platfonn ihat MPs cushmuTs use lo buikl net- 
work matiagetnent applications. In atlthtion to ofTering FIP 
OpeiiView to other network managemeni vendors, HP also 
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Platform Generates a Series ol Prcrfucts 

Chsraci eristics: 

• Lots of Parallel Development 

• Produce r/Con^umerModeMlnterprojBct 
Dependencies, Global Trade-offs] 

• Se p a r3t io n ot Platform Efl arts from 
Prtiriucr Efforts 

• Sup[}Ort and Evolution of Platform 

• ArcNtecrure ar>d Design Musi Be Explicit 
i Common Artifacts, Clear Hand-nffs) 

Chall^enge: 

• Manage tfie Complevfty 

« Manage the Uming and Resources 



markets its ov^ii suite ol' HP OijeiiVicw-biised network nian- 
agemcrtt ajipli rations. The HP division responsible for Open- 
View produces additional network management applit^ations 
in imdt^r half the time ret|uiie(l for a gmimds-up implf^menta- 
titin. This re]jit\sents a TTM red i in inn of over l^{M. Third 
parties working with HP Open View also experience similar 
levels of effoil and time savings. Unlike HP Open View; 
which is sold and vised external to HI*, most development 
labs are prodnring antl using platforms intemally to provide 
the foundation for individual product lines. 

Changing ati organization's development paiadigni lo plat- 
foiTn development Is nontmitil and reqmres a significant 
investment. Richer', more robust, and more competitive 
products along with TTM reductions of one third to one half 
are not imcommon. f otiijiing the use of a platfonn \^ith 
doing multiple products in parallel results in significant 
reductions in TBSR The lower limit for TBSP is the rate at 
which the market can absorb riew products, 

Platforin Competency Model 

The purpose of the platform competency model is to depict 
the core elements that make up aii organization's software 
development system (see Fig. 1). Eacii individual element of 
the model addresses a particulai^ aspect of hcnv an fjrganiza- 
tion's development sy.steni works. The model collect ively 
represents the overall operating model for softwaie develop- 
ment within an organization. At the same time the model is 
holographic since each of the elements contains references 
to aspects of the other elements. As a result of this, the 
model is not amenable to hierarchical decomposition. This 
will become apparent as each eletnent is re^iew'ed. 
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Fig* 4. Piwmhgm 111, pJatfonn 
(levelopnient. 

Product Portfolio Planning 

The heart of the platform c<:jmpelency mode! centers aromid 
what the busmess lequires of tlve feams developing softi^are. 
A product devel oilmen! organization is const raim^d by the 
dynamics of the marketplace and t he competitive en\iroii- 
ment within w^hich it participates. The combined market and 
c^ompeiitive forces detennine accepted operating ratiges for 
Investment, time-to- market goals, produci specifications, 
ongoing supp^^rt, cind so fin. These constrauits put limits on 
development organizations mtd establish acceptable bounds 
for TTM, TBSP. and TIM) resource efficiency (e.g., engineer- 
ing years/product). 

The result of integrating these constraints and liigh- level 
business goals is aili ciliated as part of a business plan. The 
business plan includes a product vintage chatt. which sliows 
target release dates for individual products over a multiyear 
period fsee Fig. 5), Apart from their use in business plans, 
product vintage charts are often supplemented by a set of 
product Imeage charts showing the liereditarj^ relationships 
between products and rhelr constituent comjionents. Fig, 6 
illustrates the structure used for a traditional lineage ciiart 
atid Fig. 7 show^s a platfonn -based litieage chart. Separate 
lineage charts are often constructed to higMight different 
components of a product (e.g.. electiical circuits, software 
ai^d firmware, industrial design, mechanical assembly, etc.). 
Lmeage charts are also used outside of development labs to 
depict the evolution of marketing, training, iuul support 
materials. 

The key in planning a product portfolio is deliberate, s>^- 
tematic attention focused ot^ de^ eloi.ang a prtKiuct luieage 
chart tiiat effectively addresses the organization's product 
needs. Tlw software vereion of the lineage chart sets forth 
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Fig, 5, An example of a prociijct 



what can bo arcomplished as a result of I he organization s 
platform strateg>^ Together the pro duet vintage chart and 
lineage chart pro\ide the framing for the product portfolio 
plan (see Fig. 8). The plan (*?>tablishes the targets fc.^r the 
amount of eontribulioii that a tilaifomi makes to mdivitiuai 
products. This is fretiiiently expressed as iiotii a target effort 
savings antt a targei reuse percentage (i,e.. the platform will 
reduce product investment by X engirieeriiig months and 
will provide Y% of the final product code). It also sets forth 
the goals for 1TM (time to maiket ) anfl TFSSP (time between 
successive producis) for ait entire product family. 

The iJroduct portfolio [ilan also inchides a statement t>f over- 
all goals, direct ioit, ajt<i prioriiies. DeiaiLs regarding prodmi 
definition and customer needs are mcorpomted by references 
to individual product phms (see Fig. B). Thus, the jvroduct 
portfolio platt provides the link beiween an organ ligation's 
platfornt stratt\gi^' and underlying business goals. A^ssnch, il 
acts to fdign and unify l>t)th |ilattonn atid develoiirnent teams 
and ta set tlie context for individuals in ihe organization who 
are charged with working out the implementation details for 
the platform strategy. 

Within HP, the portfoUo plan tends to be a collection of slidt^ 
built around an min* limited |)rodurt lineage chart. Tlie product 
lineage cliart is motlifu^d to sfujw the How of software ftoni 

r »^ ►^^S 

Ln=5 Hi 

Notes: 

1. M. N. and t are Ibe same producis as shown in Ftg. 5 

2. Typically, the arrows are airnolated with software sitbsysiems 
or cumponejii rames 

3. SranQhes generate multiple var^fotis of a software comp<»nent. 



the platform U) indi\ifiual products and includes a develop- 
ment time line. This package of materials is augtnented with 
details on the goals and objectives for the platfoiTU atui 
prcMluct teams. Tlie loo.se .si run tire and infonnal nature of 
HP's portfolio i>lans work wtII as long as tliere is constaJit 
comnmnication to reinforce the underlying message about 
the organijuition's chosen development paradigm find the 
link betw^een tltis paradigm and the organization's business 
goals. 

It is essential that ;ill jilayei-s understand wliy ;in orgfUiizatifjii 
has fliosen the plat fonn development i>aiadigm and w^hat it 
hopes to achieve as a result of this choice. llVs ex7)erience 
reveals that the mti ornate and expected henefit^s leading an 
organization to adopt the platfonn development paradigm 
must con.stantly he re^if firmed by management. IIP divisions 
thai have fdigncfl their rlevelopment labs around the platform 
straiegy, engendered cnnfjdence Ihroughout their organiza- 
lions, an(i provided ongoing diiection and suppoii during 
Uie ti^vsition to the new ways of working have adopted plat- 
form development more rapidly and achieved t>fHter success 
Ihrui divisions lai king active managemcnl spf>rksorship. 

Architecture Definition and Partitioning 

Since platRjmi development involves setjarating nut the 
common elements coni aired wilhiri a i)roduct family, having 
a clear and cxjilicil plalfomi archil ertun^ becomes ver>' im- 
portant. This is a key shift comtian^l to trafiitional product 
development in wiiich a product s architecture is fjften im- 
plicit fuid may not even tie writlen dow7i. In facL often the 
architectural knowledge of a (jrochict rjr set of products is 
contained witiiui the head of a suigle arcliitect or small group 
of architects. Imphcit and informal architectures work for 
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Fig. H. The components of a portfolio plaii. 

seiial indeppndpnt i>rojeots and even for parallel product 
development when teani sizes are sniaU, the level of com- 
lilexily is low, and the amount of conctirrent development is 
miiiinial (see Figs, 2 and 3). 

These conditions niake it possible for die architect or archi- 
tects to explain the product architecture informally and to 
assist otlier engineers as ihey develop their code. However, 
increasing complexity and simultaneous pail from rimlliple 
teams often forces arctiitects to spend most of their tin\e 
conmiimicating and lielping others with tlie prodiici archi- 
tecture. ^\^ile this w^cMild be an extreme in the case of inde- 
pendent products, it is virtually certain to happen in the case 
of a platform, hi addition to supporting others, architects 
need to have time to focus on evolving and extending the 
ai'chitectin-e. 

The solution to this situation is to have architecti^ document 
and make explicit the platfonn and product architecture. 
Formal architecture dociunents (diagrams and text) make it 
possible for engineers to access the architectural knowledge 
that they need to complete their desi^i and implementation 
tasks without ha\1ng to refer to the architects constantly. 
A documented arcliitectuie also provides a means througli 
which development teams can provide feedback to the 
architects so that they can tune and evolve the platfomi and 
product architecture. This not only directly benefits the 
architects, but also helps to ei^sure that a set of high-quality 
and better-iritegrated products result. Having an explicit 
architecture also makes it possible to quantify trade-offs 
between the platfonn ^ind the product m a systematic way 
and feeds the management planning processes for cturent 
and future products. 

Another key distinction of the platform architecture is tliat 
it subsumes tlie partit ioning between the platform and plat- 
form-based products. In this respect it differs from traditional 
product aichitertures which usually do not differentiate 
between individual products within a product family. Like 
all architectures, the platfomi architecture typically includes 



m^or functional or teclinology subsystems and the interfaces 
between them. Tlie chosen partitioning of architectural 
respotisibihty between platform and product teatns deter- 
mines the degrees of Ireedom that product teams have in 
their work. The shared challenge for platform and product 
architects is to determine wlicre to draw the platfomi and 
product boundary. The boundary needs to be drawn so that 
it balances the foundation and the infrastructui'e provided 
by the platform with the amount of flexibihty needed to sup- 
port value-added product featin^es. 

HP organizations struggle in their selection of the initial 
boundar>\ In practice their initial partitioning is atyusted 
over time to acliie^-e the proper balance betw een platfomi 
contribution and product flexibility. Another lesson teamed 
is the need to delineate clearly which interfaces aie jointly 
owned by platfomi and product teams and w^hich are sepa- 
rately owmed. Translating architectural constructs down to 
the level of interface, module, and code ownership helps 
avoid conflicting and uncoordinated changes to the plat- 
form. It also makes it easier to trade off changes explicitly 
since it provides a means of linking to all directly impacted 
teams. 

Product Feature Mapping 

A closely related area of the platfomi development model is 
product feat 111 e mapping. This mvolv^es the translation of cils- 
toiner needs into product features and ultunately into code 
implementation. The process of going from customer needs 
to product feature definition is imc hanged from traditional 
methods. A key shift occur s in the step where i>roduct engi- 
neers figure out how to map their features to the architec- 
ture. Product engineers may no longer have full control m 
cases where this mapping logically places part of a feature 
within the product and another part within the platfonn. 

Fig. 9 illustrates the decision-making process that engineers 
go through to map their featiues to the platfomi and prodtict 
ai-chitecture. The ultimate goal of this process is to get engi- 
neers to uncjerstand what they need to implement ancj wiiere 
it faHs within the code base. The productivity of product 
engineers is largely determhied by how^ well they can apply 
the aicliitecture and move on to implementation. In the case 
of one HP division with a newly crealed object-oriented 
arcliitecture, product engineers were not able to use the 
architectme at fii-st. The engineers' lack of experience with 
object-oriented concepts and the fact that the architecture 
was sepai'ated into logical, functional layers that did not 
directly comespond to product features made it extremely 
difficult for them to understand hov\^ to use the tucliitecture. 
As a result, no product developnienl progress w as made, 

Tlie miderlying lesson learned from this experience was the 
need for the platform arctutectiire to be explained from a 
product feature perspective, the w ay in w^hich the product 
enguieei-s thought about it. This division's dilemma was 
solved when the platfonn architect made exphcit the pro- 
cess for mappiTig featmes to tlie arc^hitecture and taught this 
to the product teams, VVTiat the architect and the rest of the 
platfomi team did was fo walk through the process and pro- 
vide direct coaching to help product engineers work through 
mappuig their features to the platform architecture. 
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Fig, B. The prcjceases involved in mapping product features tp 
piaLform and product architectums, 

Ax} equally critical dimension of product feature mapping is 
the undet^iyiding by product project niaitagers. Since project 
managers are responsible for the schedule and resource 
plan for the product, they need to know whal work their 
team will do and what specifically will be provided by tht* 
platform. Consequently, the managers must undersLantl the 
partitioning of work across the platfomi-product boiindiiry 
and ;ilso tire overhead costs of incorfjorating leusable com- 
ponents from the platform. This information iu turn enables 
thern to create an appropriate work breakdown and arrive at 
a schedule for their project. The miderlying shift here is to a 
new way of product plamiing. ^^Ithin IIP we have found it 
extremely beneficial to provide trdiiiii\g imd coaching to 
product project mmiagers to help them with their phiruung 
tasks. 

Test Architecture and Strategy 

The plat Rjrni aichitecture not only helps define the dividing 
line between the platforni and products l>ul iilso drives 
changes in test strategies and implenientation. Since die 
platfonn provides comi)onents, modtJles, ajid subsystems to 
product teatns befoTi- fin ill system integration, some degiee 
yf lesliog of platfonn work products is necessary before 
tiiey are delivered to the product teanis. Ideally^ tlie platform 
team fully tests its work products so tliat product teams can 
focus on their specific extensions to the platfonn. Tliis divi- 
sion of test effort, results in an overall reduction of tJie effort, 
defers, and schedule once the first platfonn-based product 
is released. 

Unfortunately, several factors complicate this itieal, It may 
be difficult to fully test platform functionality without ackli- 
tional product-specific code, and in jn*"uvv ca^es platform 
functJonEdity is developed concuneiUly with pnKlucI func- 
lionaliiy rather than sequentially. Both result in luwi*r code 
tiuality juvd potentially increase Itie testing hurderi placed on 
product ti^ams. Prothict teams usually cann<jt afford to be 



the de facto ^'stems test organization for the platform be- 
cause doing so comproniises their own goals, and in particu- 
lar, their schedule. If product teams g€t overwhelmed with 
defects or integration problems passed on by the platform 
team, conflicts in schedule, priorities, and ev^en team rela- 
tionships arise. Furthermore, since platform and product 
teams often sit in close proximity, problem solving gets 
driven by personal priorities and urgency ratlver tlian an 
objective, organized approach. As a result the organizations 
cumtdative teeing effort may actually increase, negating any 
potential savings. 

Thus, a key factor of succe^fully using the platform develop- 
ment approach is the creation of a shared test architecture 
and strategy tliat ensures the delivery- of high-quaht>' plat- 
form components, thereby enabling product teams to focus 
their developmetit and testing efforts on product-specific 
features. The goal of the test strategy is not to outline ex- 
hausiiv ely the details of how the appropriate level of quality 
is hiiilT into deUverables, but rather to describe Ihe overall 
risk management and test approach. The test strategj' makes 
reference to specific product niyeslones, checkpoints, m\d 
activities. As expected, code drops correspond to key points 
of synch!*oni2ation between platform and product teams. At 
each code drop, there are specific outcomes, questions, and 
measLucs thai describe both i>roduct and platfonn goals. 
Based upon these expectaiioas. testing and risk managenient 
activities can be determined. The test strategy specifies 
what these activities are and when they occur, but not the 
details about their execution. For instance, the test strategy 
may call for design review^s and itispecUons at particular 
points along the life cycle. The specific kinds of reviews or 
inspections, to what degree, m^d of what documents, will 
depend on the types of risks that need to be mitigateil. 

Tlie test arc^hitecture focuses and streamlines the multilayer, 
midficyde test process. Each element in the test architecture 
is linked to the product architecture at the component, sub- 
system, interface {integration), system, or solution level. 
The individual elements also serv^e to set the scope and pur- 
pose for test suites. Fiir instance, multiple suitc*s may exist 
to test subsystems for functionalitj; usability, perfr>nnance, 
or reliability. Once each test architecture element is defined j 
it gets mapped to the test strategy and reconclletl with de- 
velopment and milestone dependencies. 

Without a test architecture to define the scope and purpose 
of a test sutte^ cycles in the test process will often bv rt^dim- 
dant, increasing the time and resources used in each product 
team. A product and test architecture can also facilitate the 
development of a platfonn regression test strategy. As a 
platform is used in uiore projects, the platform team v^ill 
want a method of ensuring tfiat chajiges made to the plat- 
fonn don't inadvertently impact the functionality of one 
product over anothen 

Organizational Structure and Work Partitioning 

In addition to the many architectinal implications for devel- 
opifig products under the platform development paratligm, 
there are many numagernent issues thai need to lie ad- 
dressed. Tlu^ HiK^ctrunt of management concerns is quile 
broatl and includes defitung the context witlun which teams 
are configured ^ deliverai)les specified, and conOicts re- 
solved, and defining how teams conununicate witlt one 
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a]K>tiher One pivotal iiiaiiageintMit activity is the defiiiition of 
the oi^anization's stjxictiire and its prcK^esyc*^;;* for paititioiiing 
work. 

Crucial diO'erericus in individual roles between platform 
development and t raditional developnR='nt paradigms are at 
llie lieait of RtriKlural and work-assignment issues. Platfunn 
development does not result in the creation of new roles 
within an orgaiiii^atitjn, ratJier it causes existing roles to be- 
come exjilieit and more fonnal. In traditional developuR^Jit 
projects, (me or mare individuals fultlll tht' roles of program 
managementp project niaiuigement, people man.agerneni, 
product arcliitecture, and process archiieclure. A brief defi- 
nition of each of these roles Is contained in Table I 

Table I 
Product Development Roles 

Role Responsibilities 

Prograi 1 1 1 rttegrate and coordinate al h he li met ions 

M anagen tent involved in deve 1 op i 1 1^ I he p rod u c t, in c I u d - 

ing marketing, developnient, learning pri>ti- 

nets, and Held support. 

Project Develop anci ixialntain the project budget 

Managemenl and schednU\ alloc ate resources, and 
Mumage work assignments. 

People Perform employee training^ skill develup- 

Management merit, perfomuinee evalualion, salary 

atkninistralionj and cjther adniinistrattve 

and legal tasks. 

Product Develop and evolve the product architec- 

Arcliitectin'e tare including coaclung and mentoring 
others on its application and use. 

Process Define and integrate the vai'ious processes 

Architecture used durirtg [jroduct development, inclufling 

how work is done, extensive eornmmiica- 

tion, ai^d process training. 

Until fairly recently within HP the roles ol projecl nvanage- 
mejit^ people manageEUenlj pixiduct architeeture, ami |>n> 
cess architecture were tlUed by a single project manager. 
This is still common in some HP di\lsions. As a result of 
mcreiising product complexity, many divisions have created 
explicit positions for product architects tmd have thereby 
removed tliis rt^spoi^sibility fro eh their project managers. 
Some divisions have gcme farther and pulled process archi- 
tecture resijousibilities from then' project manager positions 
and atlded Jiew process tuchiLect positions. The separation 
of responsibihties is especially important for platform devt^l- 
opment since multiple teams are working in parallel on 
products withui a single fatnily. The larger scale of tins en- 
deavor makes it diftlrnlt for any one inciividual ro Juggle 
combinations of these roles while simultaneously attenrling 
to the broatl scope that accomiJiu\ies each role. As a result, 
individual jobs tend to be more speciatizeii imd better de- 
fined m this paratiigm. 

Tlie key sMft m orgaiiiicational structure for plati'omi devel- 
opment occurs wlien sepaiate platfonn and product teams 
are created (see Fig. IM). The sepaiation of platfomi and 
pniduct teams heroines a necessity when tJiere is more than 
one product under development at any given rime. ILP's ex- 
perience has sliown that having one team simtdtaneously 
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develop a platfonn and a product while another team works 
on a (Hffereni product is unworkable because of a perceived 
lack of triisi between teams. The underlying issue here is 
perceived favoritism by the platform manager for the plat- 
form temn's own [jro<hict effort. Tliis perception is hard to 
ctyunter and retiuires an explicit w^ay to addiess confUcl of 
interest Issues, (lur solution is to separate the producf 
responsibility fiom the platfoim to ensure diat the plaiJoMii 
effoit is equally shared between the various products. This 
solution takes advantage of an organization's lepoiling 
stnictiue tuid relationships. 

Just picking an appropriate organizational structure is not 
sufficient for ensuring that work gets done smoothly, [ndi- 
vidual work assignments need to be aligned with the report- 
ing stJiicture. Otherwise, indi\4duals mtliin the oiganizatiori 
can wind up spenduig a lot of their time tryuig to figure out 
who does what for whom. In llFs exjjerience, fonnalUIng 
individual roles mxd responsibilities helps a lot. It simjjlilles 
the trackuig of individual accountability and provides tJie 
context for optimiiiation of work assignments. In addition, 
management leailership and direction are needed to help 
people cotie with ambiguity and to addiess coorduiation of 
activities across team boundaries. 

Partnership Model and Contract 

Management, through its own style and working relations, 
sets the tone an^i t orUex! for huw teams work together. As a 
result, mfinagertient behavior lajgely detennines the kind of 
part nei*sl lips that will exist within the tlie organization. The 
puipose or having a pattnership model and contract is to 
make explicit how teams are to work together. 

The reuse of software components futnlamentally mvfjlves a 
producer-cunsumer relationship) in whicii one or more teams 
produce software assets that other teams use. In the case of 
I^iatfoiTn developnteni the platfonn team is tlie producer and 
the product reams aie the consumers. How the teams work 
together determines the overall success of their combined 
effort. Team perceptions of autonomy, accountabdity, and 
control all w^eigli heavily m setthig the context and bound- 
aries for how- teams can work together. 

The staJting point for establislniig a solid w^orking relation- 
ship Ls given by the organization's existmg social cm d cul- 
tural nonns. Within HP we have fomid that if eitlier team 
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seeks to gain sole conirol of the relationsliip, the platform 
development system will fail. The key shift that is needed is 
for all teams to think and act as full partners. The noliou of 
working together on a collaborative effort creates a wm-vtin 
siluation and a\'Oids the inherent conilici in one team being 
!^ijperior to another, ft jilso blurs the thstinctioii between 
piatform and product team roles and ilius provides a greater 
degree of flexibility in work assignments (refer bac*k to 
Fig. 9). 

U hile the partnership model defines the preferreti working 
niode between leants, the partnership ron^i<i is tiie ultimate 
agreement that is reached between product and platform 
teanLs with respect to their niiitual deliverables. As such, the 
partnership contraei incorporates and builds upon the part- 
nersliip nimlef k contains the si>ecifics of what gets deliv- 
ered, by wftom it is delivered, and when it Is delivered. It also 
includes the explicit contimmieation channels that ynh be 
used between tean\s as well as tJie mecFianisnis and proto- 
cols for handling changes and ex<:eptiuns. Tlie paitnersMp 
contract is not a legally bindmg document, rather it results 
from discussions betw^een platfomi and product teams. 

Within HP llie process of negotiatiitg a partnei-ship contract 
is more importiitit than the contract itself For each new 
product, the corresporidir\g |>larform aiul product team 
members sit down ;md wt>rk through a series of questions to 
arrive ata nmtual agreen^ent tJiai supports the organization's 
product portfolio plan. Tlie final answers to the questions 
can then be bicoq>orareci into the platform and product leiiin 
plaiis as appropriate (see Fig. 8). This negniialioii pnieess 
serv^es as a mechanism for jouil plaiuiing iUid lays the 
foundation for die ongoing relationship between the plat- 
form and produti teams. 

Management Processes and Steering IVams 

Mai lageri lent | nut esses provide luoclianisms tor managing 
(Higoing team relationships and for adtlressing changes in 
lyofh iulenial iUKl exiemal requireineJits. Thi^ processes in- 
c hide mecjiaiiisnis for inteqiroject plajinuvgiuid resource 
priorilixationf tracking and controlling progress, and recog- 
nizing, escalating, and resolvuig issues. At an aggregate level 
these prtjcesses need to l>e iiligned witli the pr<Hiuct porthi- 
lio plan. Miuiagement is responsible for achieving aligniueiit 
;iiitl foj^ providing their people widi the means to work low aid 
the overall strategy. 

A key shih m platibnn developniein Is the creation of stmul- 
mg teams to fleaJ with ongoing issues. In particular, manage- 
ment typically cliajlers a nianagemeiu steering team mid an 
architecture steering teatn. The miuvagement steering team 
is made up of tlie portfolio manager, die (jiaifonn manager, 
the product team ntanagers, and the process architect. The 
teaju may also in«*hide the manager of a sef)£U'a1e quality or 
lesiing team, 'Hie te;mi is restiojisihle lor moiutorin^ pro- 
gress, nifiintaining resources and schedule synchrouizatiou, 
and resolvhig daily operational issues. The existence of tlie 
team is not meant to replace ongoing, onen^n-one work. 
Rather', team meetings serve as a forum foi' surfacing issues 
and eslahlishing litikages for issue resolution. 

Architeeture steering teajns are staffed by senior designers, 
aj'cliitects. and technical people. They also include m\ orga- 
nixal ion's process ai'chitecLs. Their charter is to j'ocus on 
managing tiie overlap between the platlbrm and product 



architecture. The team is responsible for ensuring that the 
architecture can be used by product teams effecthely and 
for managing tlie evoludon of the arcliiteeiure so that over- 
all arrhitectuml integrity is preserved, 

Ulthin HP. luaiiagenient and architectural steering teams are 
lisixl at muitjple levels. Tlie number of teams and tJieir struc- 
ture depends on the complexiiy of a division s business, the 
nnnil)er *>f product lines, and the ninnber of distini'l platforms 
wttJtin Liitise proiluct lines. Generally, one steering learn is 
creaieti per plaifonn. In our experience steering teants work 
well when they art* stalled with key stakeholders and liave 
clear, well-articulated charters, Managemem needs to set 
appropriate team expectations and model new desired te.am 
behaviors, especially if Uiey tlaffer from die orgaiuzalions 
existing nomis. 

Communication and Feedback Model 

The success of £ui organixatiou s jilarforni develoiMuent sys- 
tem Ls largely a function of the strength i>f its ctHuiuuiik'ation 
and feedback paths, (jood eonimunii^aiion between platfonn 
and product teams is essential for reducing unexpected sur- 
prises anti supporting rajiid decision making. F'or communi- 
cation to be effective, the right information nuisl reach ap- 
propriate individuals in the organization at the projjer time. 
Incorrect, i[)ap|>ropriate, or out-of-date information has httle 
value, and in fact, can be comiterproductive. 

The attributes of a good communication and feedback 
motlel are that it: 

• Specilies coiumunicalion roles mid responsibihties 

• Enumerates tiie tiLKoruHny ui infomiafion types 

• Identifies explkit c*onmiunication hnks, channels, and 
padiways between teams 

• Bstal>lishes triggei-s for certain types of utfonnatioital 
excluuiges 

■ Creates a context for continual organizational learning, 

The communication and feedback model can be diouglu of 
as an architecture for the movement of infomiation within 
an organizatiou. As sncli it j)]ays a major role in hel|jing to 
ensure thai the rigiit iiduruialj<fn gets to tiic lighr phu e at 
the right time, 

Tlie key shifi for Jiinst organizations is copiiig widi the need 
for wider dissemuiation of hdormation. M flu* number of 
interdependent teams mcreases, the number of stakeholders 
with interest in a given piece of inforfnaiioii increases. Put- 
ting together a cr jumuinicatioJi model in the foj u^ of a data 
How diagriun In l|>s teams itteniify who neetis U) know about 
[>lans. assigmuents, issut^s, staULs, best practices, and sue- 
chesses. However, getting infonttat ion to [low is not enough 
because tlu^ recipiejUs of tlie iittbrmation necnl to be able to 
respond and act on the informatioi^ if a^jpropriaie. The chal- 
lenge for individuals transmit ting infonnatiott is to gather 
fee^dback on th** effectiveness of their cominnnication <uid to 
tujR- future inforiuaUon exchanges. Having individuals auto- 
mat it rdly check ilieir 1 omiiuitiicHtion ('ftVcUveness serves to 
tniild iuid prfanoteorgiuiizatiouiil learuing. 

Within HP we have seen sigitifjcant gains in organizational 
perfoniiance as a result of elimuiating conuimnication sli^^ 
page and o|>timizing its effieiency. Pleasant, cle^^u comintijii- 
catjon lower's organizational siri'ss and makt^s it uiusier Un 
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people to work together It also enables faster and higher- 
quality^ decision making. Many divisions are using (^inail and 
World-W^ide Web publishing to make pliitfomi information 
more readily available to product teams. 

Support Model 

It goes wiiiiuiil Ha>it\j| thai for produc-t teams to be effective, 
they must be ai.>le to understiuid, incorporate, and success- 
fully use die pltilfonn. Tiiis includes ttieplalfonn architet- 
liiie. lis toniponents, development tools* and the underlyhig 
pioct ss infrasinK'ture. The supi>on model addresses how 
Ijnjtiuct teams get assistmice iis they work to incoriKjrate 
plattbjm eon\ponerits initj their products. It provides the 
means by wiiich product teams get help in the following 
situations: 

• Acliiei-ing understanding and resolving "how to" questions 
(e.g.. How do you do X? How does Y work?) 

• Sorting out instances of something not working as expected 
or not meeting a product's needs (e.g., There appeal's to be a 
bug in X. Can Y i>e adapted to support, product feature Z?) 

The <.*reation of a support model starts with the identification 
of detailed support reqimenients and establishes the mechan- 
ics and logistics for how platfoiTU and ju'oduct teams work 
together. It includes both initial training and ongouig sup- 
port during implementation. The support model identifies 
the types of support provided, the mechanisms tlu'ough 
which it is delivered, aB<l the oveiM service level expecta- 
tions (e.g., iy|>ical luniciround or response time). The model 
covers activiues such as providing docrunientatioii deh^ering 
training, answering questions, making defect repairs, and 
releasmg eiiliaiicements. Il also sets forth supi>f>rt roles and 
responsibilities — to wliom to go for ai^slstance. Finally, it 
uiclucles an escalation path for resoKing impasses. 

The concept of a support model is not new. In fact, most 
organizations have im explicit model Ibr supponing I heir 
customers. The key shift in platfonu development is the 
creation of an explicit suppoit model IVir in-house t>roduct 
development work. Tlie need for (lutting formal structures 
in place increases with the niunbei' of product teams work- 
ing in ptu'^tillel. hi HP's experience the most effective platfonu 



support models are developed jointly by platform and prod- 
net teams. \¥e have* fountl that inciuding a set of agieed-upon 
perfonnance measures serves to cahbrate and set individual 
exj^ectations. TVpicaJ measures include support availability, 
response time, and liniits on tiie maximum number of hand- 
offs. Fin ally, the support model's scope extends beyond 
product construction iuid needs to include product planning 
and testing. 

Platform and Product Life Cycles 

In aticUi ion to the need for more fomialized support, platform 
development results in many changes to an organisation's 
development practices. The deveitjpment process changes 
are incremental in nature and generally reflect a fonnaliza- 
tion and refmemem of existing practices. An organization's 
platform and product life cycles provide the structure and 
coniext whbin which individual processes fit Mke other life 
cycles, they are cliardcteiiised by m^or phases with associ- 
ated goals, activities, deliverables, and checkpoints. 

Fig. 1 1 shows tlie imderl>ing structures of the platform and 
product life cycles. The ni^or phases of the two life cycles 
are very similar. Since the platform architecture and compo- 
nents flow from I he pkitfonii into products, there is a depen- 
dency betw^een tiie tw o life cycles. The close couphng of tiie 
two hf e cycles represents a key shift compared to autono- 
moiis development projects. 

The output of the platform investigation phase is a definition 
of the o\'eri?ill system architet tuie and answers to the follow- 
ing (juestions: 

• Wliat is tlie platform? 

• How is it intended to be used? 

• How will it he delivered to product teams? 

• How win it be supported? 

• How will it be extended and evolved over time? 

As part of this phase, t he piatfonn team identifies necessacy 
changes to existing develoj^ment practices needed to sup- 
port platform development. The proposed ways of domg 
thmgs fomi the basis for what is called tiie piatfonn umt/. 



Investigation 



i/L 



Keration and 
Interim Releases 



tmplemEnlation 



Final 
Release 



Piattortti 
Vefsion 1 



a ■ , Feasihilitv Archi ecture *. , \_. '" nj^raian 

Requ rements »t *- . . n m . Develapm^irt structure 1 1 1 ' ^ a " 

n t ' Validation Defmrtion ,%. ■ r. . Test 

D^''"'^'*^'* P'a« Derelopmenl p^^^ o^gjg^ rmplemeni Test j As Needed J 



Input and 
Feedbacic 



Product 1 



Irtptit and 
Feedback 



Invest! pall Qo 



\/l 



Code 
Deliverables 



Feedback 



Iteration 



M/n 



Produci , ...,., Plailt»nn ^^f"""^- „f'J?''* Code Co«simciion 

. Feasibility -^ur.^^...^ based Platfofm 



Plan structure P'an Besip Implemeni Tesi 



■— Product Z 



■ 



Fig. 11* Thf? platform aiid product devdopnient life cycles. 
60 Aii0ist 199fi Hewlett-Packard Joiinial 



)Copr. 1949-1998 Hewlett-Packard Co. 



The deliverables from the investigation phase of the plat- 
form need to be essentially complete when product teams 
move from requirements de^nition and feasibility validation 
to insLantiaiing the platform architecture and building upon 
the platform plan- Tliere is a similar dependency in the 
implementation phase between infrastructure development 
and use. The infrastructure consists of the processes and 
tools that support the platform way. 

Tlie implementation phase of the platform life cycle often 

overlaps with product implementation work This arrange- 
ment requires coordination between iterations of platform 
and product code construction. The use of an evolutionaiy 
development methodology, which subdivides code construc- 
tion into a series of short plan, desi^i, implementation, and 
test cycles, provides one way to achie\'e the needed coordina- 
tion (see the article on page 25). In addition to continuous 
feedback and integration of platfomi iind product compo- 
nents during implementation, continued support for platform 
use is essential As meittioned earlier tiie test architecture 
and strategy will detennine the overall approach to verifica- 
tion and validation by the platfonn and product teanxs. 

The platform life cycle does not end when the platform com- 
ponents for all currently active products are finished. Rather 
ii wraps around and a new m^ estigation phase begins. In 
subsequent iterations the platfomi architecture, p roc esses ^ 
and components are modified and extended based on new 
requirements. The boundary t^etween the platform and prod- 
ucts may change as certain features migrate into the platfonn 
so that they can be used by subsequent products. 

HP's cimiulative exjjerience underscores the need to separate 
phitfonn and product Ufc cycles. P\irthermore, life cycles 
must be linked to existing hardware Life cycles^ or software 
work may not begin until after the hardware prototype is 
done, thereby deiayini; product inlrodiu'liou. We have also 
learned lliat securing future pruduc t input diirini^ the devel- 
opment of the overall system architecture iind defiiijtioa of 
the platform way is essential to building strong interteam 
relatioitships. One particularly effectiv(^ way to engage future 
product teams is to involve them in signing off on platform 
checkpoints. 

Development Model and Development Process 

The deveiuimient model mui the developmeiU process de- 
scrilie how new functionality is createtl. They {*over the pro- 
cesses used in the creation and enhancement of a platform 
module through its integration into products. They are anal- 
ogous to a niodule or component life cy ck^ in tliat they cata- 
log the development steps spamiing fioni construction to 
final use. Since platform modules and components are ulti- 
mately used by product teams, the development process 
really includes two different peispectives: software asset 
flevelopnient and softw^are asset utiMzation. The key sliifl in 
|)latfcjrm <levetopment is formalization of these perspectives. 

in cases where the bomidaiy^ between platfonn iuid prodtKJts 
is diffuse, a single process incorporating both perspec!tives 
can be used. The common process can be applied by botlt 
teams regardle^is of whc^iher I hey were building (>latfonn or 
product furu'lifiuality. On the other luuuL a sharp l)oundaty^ 
has the advantage of providing ])rodu(i and tilatforrn teams 
with greater aunmotiiy over their work, since each cati use 
(iiffcrent processes. For exarnplc, if ttie plalforru-jjroduct 



interfece Is confined to linldng a set of libraiy modtiles, 

then the platform might be designed and built using object- 
oriented methods and tools, while product teams might use 
traditiona] structured programming methods and tools. 'Hiis 
decoupling is not without cost t>ecause the use of different 
methods and approaches makes it harder for te^ns to com- 
municate — consider the difference between object-oriented 
prograntining in CV^ and functioital programming in C. 
Furtiiermore, its verj^ existence rai^ the cost of modifying 
the platform and prcxiuct boundarj^ and makes it signifif^ntJy 
more expensive to migrate finictionalitV' across the boundary- 
It also reduces resource flexibLlit>' by making it more diffi- 
cult to move engineers betw^een the platform and product 
teams. 

Exi^erience within HP has shown ti^at platform development 
proceeds smoothly when platform and product teams follow 
highly compbmentar>^ development processes. By agreeing 
to use common methods and tools, platform and product 
teams make it easier for one another to cross the boundary 
between their work domains. Tliis provides flexibility so 
that resource use c^m be optimized. It also allows for evolu- 
tion of the platfonn tlu-ough incremental redefinition of the 
platform-product boimdajy. HP division's have reaped signif- 
icant benefits from having documented development pro- 
cesses since these reduce the support burden for bringing 
new engineers up to speetl on how things are done. 

Delivery Model 

The deUver> model defines how platfomi mrxluIeSf compo- 
nents, and subsystems are passed on to product teanrs. 
Platform deliveries arc essentially a niicrocosm of the prod- 
uct release process since they cover lite deptli and breadth 
of what a development organisation delivers at the manufac- 
tiuing release (M/R) of a product. At M/R, a final production 
build is ilelivered to manufacturing along witl\ a set of re- 
lease notes, documentation, and other supporting material* 

Final release may be proceeded by multiple iterations and 
intem\ediate releases, especially in the case of contplex 
i^stems products. Ftrrthemiore, each constituent part of 
the whole product can be delivered in a different way. For 
examjfle, wiiile |jiiysicid hardw^are and firmware go to mai\u- 
facniring along with detailed assembly, calibration, and 
packaging instructions, the products software drivers may 
simply be given to a third party for replication. 

jM I ho ugh most organizaUoas have long had internal hand- 
offs among teams, the key shift in platfonn tlevelopment is 
nmking these handoffs aiid deliveries exijficit. While f he 
platform life cycle outlines the types of artifacts thai get 
delivt*red and when they are delivered, tlie plal fonn deliveiy 
motiel provides specifics on what is delivered and how it is 
delivered If a delivery is analogous to passing a package 
From one teait^ t.t* anot her. dien the delivery model corre- 
sponds to a packijig ILst or bill of materials. 

The delivery model also specifies how the pat kage is dehv- 
ered to the protluct teimis. The cieliver^' mechajiism typically 
falls somewhere aiong the continuum from push to pull, hi 
the push case. Ihe platr<tnn (earn delivers ixackages when 
they are ready. In liie jiull < rtse. junduct teams request pack- 
ages when they wimi theiit. There are prcjs and cons to eat^h 
apprtjach. The push approach caji force product tean^ to 
use sorrt*:tiiing before they are ready, while tlu* pull apjiroach 
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can cause the plalforni team to support multiple versions of 
the saiue component. Within IIP most ctivisioiw have Ladoj^tecJ 
a hyl>rid model in which IjoUi push aud pid] app roadies are 
used dependii\g on the type of each deliverable. 

Althoiigli it might be Lenipting to rely on an ad hoc delivi^^ 
niodel. HP's experience shows that havinjJ iin explicit, fdr^ 
inal delivery model is essential to ensure that product teams 
can successfully use the platfomi. This is particularly true 
when multiple j^roduct teams ^ue simultaneously using the 
plalfonn. Fmtheniiore, the dehveiy model prr:>v'ides addi- 
t iojial means of supporting product team members. 

Validation and Test Processes 

Another important aspet t of platform atid product develop- 
ment is the accompanying validation and test processes. 
These processes correspond to the (actics tisecl to imple- 
ment the overall system test strateg^y and architecture, 
including the seleetjon, iniplementatioti, and execution of 
appropriate testitig methods and pro<'edures. 

In traditional product development , testing is often relegated 
to the back end of the Ufe cycle and almost becomes a certi- 
fication step intended to ensure that the product meets cer- 
taui quality and reliability retjuirements. In t ontrast, j>nigres- 
sive develo|:iment organizations view^ testuig as a |)rocess of 
verification and validation that can be applied tiu'oughout 
the product life cycle. These organizations conscientiously 
perform verification and validation activities as early as pos- 
sible in their life cycles to catch defects eaily and thus re- 
duce overall development effort and shorten back-end cycle 
time. 

Organizations that have successfully made the shift to early 
defect detection see testing for platform development as a 
variant of their current processes. For others, the move to 
platform development forces a shift in testing emphasis to 
architected, early defect detection. Wlien this shift is not 
made in time, platform development projects become vei^y 
painful and can even fail 

The key shift, needed is fox tlie platform team to certify its 
w^ork products before they are delivered to product teams. 
Many testing techniques cim be used to ensure appropriate 
levels r>f quahly througliout the development life cycle, 
Tecitniques such as formal design techniques, reviews, antl 
inspections caiv be used to catch errors before moving mio 
imjilementatiorL Prototypes can be used to dentonstrate 
feasibility and validate certain design constnicts. Coding 
st^idaids help to ensure cotie i)ortabiiity and bountis check- 
ing is accompbshed via assertions in the code. Dtiwnstrearn 
activities include white box anti black box testing, unit test- 
ing, and regression testing. The stability of code modules or 
product components is verified by doing trequent. regular 
builds. Finally, integration testing is used to ensru'c proper 
cohesion between platfortu and product components, Tliis 
list of possible verification methods is !)y no memns exliaus- 
tlve and many additional types of tests arul quality methods 
exist. It is incmnbent on tlie teams to pick tliose methods 
that best address their particular project risks. 

Once the platfomi teaiti has developed processes that meet 
the deiiverj- criteria of the product teams, the second key 
shift is for the product teams to leverage and complement 
tlte validation and verification already accomplished by the 



platform team. This shifi involves making changes in the 
product test process to leverage the test architecture and 
focus test cycles cm product-specific contributions and their 
integration witii the platfonn. K product teanis find thern- 
selves testuig platfoiTii components, tiien something is wrong. 
This is analogous to having teams that use C compilers do 
testing on tiie accompanying C libraries. 

Experience within HP indicates that when the product 
test strategy is not revisedj tmneeessary redundant testing 
occm^s. In this case the platfonii is billy lested as part of 
eveiy product. As the number of simultaneous products 
under develop ut en t increases, so does the burden placed on 
those doing system testing. Hie eut] result is repeated testing 
of parts of the platfomi, al lugli cost, and with little added 
risk reduction. 

Development Tools and Infrastruetiire 

Tiie Ilnal element of how^ engineers midcrtake their work is 
made up of the development tools and infrastructure that 
they work with. The tools needed for platform development 
^u-e no differet\t from those useci in other development acti- 
\ities. However, platform development often demands more 
from the devehjprnent tools and infiastnicture than tradi- 
tional product (ievelopmenh Since platfonn development is 
usually accompanied by a lugher degree of complexity, tool 
flexibility and robustness often become Issues. Key sliifts in 
this area have to do with (1) formal tracking of project issues, 

(2) ai*cbitecture, design, and process documentation, and 

(3) robust configuiation management. 

Ad hoc issue management breaks down in the case of plat- 
form deveUjptnent because of the large mmiber of stake- 
holders extenuii t(j the ijiatform team. The use of a process 
and tool to maintain a database of issues and their resolu- 
tions not only supports the cjngoing issue management, but 
also pro\ides a means of capturing historical inlomiation 
about key project decisions. 

Design documentation and automation tools help with the 
generation of docun\entation that is essential for success- 
fully snpjjorting product teams. Standard design tools also 
help to ensure consistency across the w^ork of the members 
of the platform team by providing conmion formats for indi- 
\idual work products. 

Flnallyt tools for simple version control ai^e replaced by a 
full-Oedged source coidlguration management system that 
provides tJie needed horsepower to adtliess concurrent i)lat- 
fonrt and product devekjpment needs. In HP's exi^eriervce 
moving to a robust source configuration management sys- 
tem leads to new w^ays of working. The transition to more 
sopliisticated processes Ibr version, budd, and workspace 
management is nontri\iaL 

Metrics and Measurement Processes 

Metrics and measvuv merit processes cut ao'oss all the other 
elements of tlie platibnn development model These pro- 
cesses are used to know how^ tilings aie goiitg lUkI to flag 
potential exceptions. Although any organis^ation can collect 
metrics, the real question is wiiether or iiot the organization's 
metrics are driving effective decision making. A gootl metrics 
program measures the right ihitigs and then provides a 
means for acting on the chita collected. 
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Since metiics communicate what is important and focus 
organizaiionai energj. they provide a mechanism for shaping 
anti institutionalizing the platform way of domg tMngs. Con- 
sequently, they provide a means of reinforcing the new be- 
haviors that are required for platform development to be 
successfnl A set of metrics can be defined for the elements 
of the platform model in such as way that the metrics corre- 
spond to how well each element is ivorldng for the organiza- 
tion. Defining this set of metiics^ roiling them out, and fol- 
loT^ing throu^ correspond to the key shifts hi this area. 

The managemeni processes and steering teams and the plat- 
fomi and product life cycle directly link many of the metrics 
to decision making within an organization. An organization s 
management processes and steering ieanis provide the con- 
text for ongoing review of metrics and for taking appropriate 
foDow-up actions, particularly those related to plantting, 
management, and support issues. With respei^t to tiie arrhi- 
tecture and development elements of tlie platform compe- 
tency model, metrics are included as pan of die platform and 
product life cycles. The metrics for intli\idual elements are 
tied to specific life cycle checkjioints (refer back to Fig. 10). 

The metrics that an organization collects and uses largely 
depend on its business require men t.s and level of maturity. 
A technique that has been particularly effective withm HP is 
the goal/question/nietric ptiradigni (GQM).-^ The principles 
behind GQM tire rather simple. It begu\s witli a goal or set of 
goals, de lines a set of questions that pro\ide \isibiUty into 
how well the organization is doing at meeting the goals, ami 
identifies a set of measures that provide ansvt^ers to the 
questions (see Fig. 12), Smce GQM is not necessarily iineai; 
it can be used as a means of exploring and clarifying the 
meainng of a slated goal. This makes it a i>owerful teclmique 
for definuig the metrics for tl^e indivUlual element-s of the 
platform model 

Values and Reward System 

In most orgcinizations individuals act based on ihvir beliefs, 
values, and understiinding of the consequences of their 
actions. Although people do extraordinary thiitgs when pre- 
sented with dire consequences, in most cases an extraordi- 
nary level of performance is not sustainable. Higli turnover 
and burnout in development organizations are ofteii the re- 
sult of continually demanding intUviduiil and team heroics. 
The nonns for individuitl and team betiavicjrs depend on an 
organization's ctilture which in tuni is sliajjed by the collec- 
tive beliefs and values of individtiais within the organization. 



Goai: Reduce software inle grit ion time. 

Questionl : How many builds ^re there in iKe ietegiatien litna? 

htetrici ffuntbar of builds. 

Quest! on 2: H o w tofig do es e n e ve ra ge b uif d tak e 7 

Metr J c: Ca I ende r ii me^ en g i ne eri eg effort. 

Question Zx How ma n y u np I a nne d b u i Ids af e there ? 

Metiic: Number of planned builds versus uniileoned butfds. 



in 4^: H o w ma ny la i I ed bui Id s oecu r? 

Number of failed builds vei$u$suct;e$^1ul builifs. 



Fig. 12. .\ji lixatiipkj of tiiegoal/questioti/nietric paradigm (tiQMJ. 



The importance of shaping oi^ganizadonal culture to support 
platform development caiuiot be understated. The first step 
in making the transition to new behaviors for platform de- 
velopment is to identif>* the v^ion for how things will be 
working when platform development is fully funct toning 
within the orgamzation. The vision needs to be vivid, rich. 
mid descriptixe. Having a vision is not sufficient to get an 
oiganization to its desired state. Tlie organization s culture, 
v^aJues, and rewards must be aligned with the vision. 

The organization's recognition and rewards systems play a 
m^or role in reinforcing the desired new behaviors that are 
part of the platform w^ay. It is exirenieLy important to align 
j>erfonnance evaluation, recognidon, and reward mechanisms 
with behaviors diat sinniltaneously support aclue^ing plat- 
fomi, product, and business goals. A coninion failiire is to 
assume that all of these niechaiiLsms and sj^stems aie ahgned. 
The key sluft is to link t he desired state explicitly to specific 
roles and activities within the organization and to make sure 
that those roles, activities, azid behaviors are reinforced. 

Witiiin HP we achieve aligiinient by worldng issues bodi top^ 
dovTn and bottom-up. As a result we integrate business tlunk- 
ing with the lo|?is!ical operational, and personal attributes 
of vision in such a way that individuals throughout the orga- 
nization knoW'* flow they fit in. We have also found it neces- 
sary to revise existing peifonnance evaluarion criteria to tie 
them to aji organization's platfonn dev'elopnienl strategy, 

Ecj^uits 

Vaiious divisions within HP have realized productivity and 
efficiency gains as a result of adopting the platfonn develop- 
ment paradigru. The degree of improvement varies between 
divisions iittd further gains are expected since many divisions 
are still in the midst of their transition. 

One chvision has doubled its product generation capability 
from an average of two to four new products per year with 
no increase in development staff. Another division has cut 
ils time between product releases (TBSP) from twelve to six 
months and has slowed stiiffing growth despite an e.xp<jnen- 
tiid increase Iti the number of new product releases ijer year. 
TMs division's staff grew^ Linearly w^hile the number of prod- 
uct releases went up almosi: tenfold over a three-year period. 
The experience at another division inclufletl increased prod- 
uct consistency, improv^ed similarity between [jnKlncts within 
a product family, and better coverall quality. These benefits 
ultitnately enabled this di\ision to offer a better integrated 
solution to its customers. FurthernK)re, this division cut its 
time to market for new [iroilucts and has reduced the tin^e 
required to bring new staff on board and make them fully 
productive. 

Fortunately, organizations do not have to wail until diey 
contplete the txansition to platform development before they 
start reaping benefits. Since platfonn development mandates 
a higher level of organizational maturity and individual skill, 
it helps to institutionahze solid er\gineering practices. Typi- 
cally, there is an incremental jiroductivity gain associated 
with each improvement in exisi ing engineering practices. 
Thus, an orgjmizat inn's tr;uisitioi\ to platfonn development 
effectively compoiuids miihipJe productivity^ improvements. 
Benefits can be reaped all along tJie journey and not jtist at 
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the end. In fact, for ilioae HP divisions that have had to can- 
cel or delay their platform efforts, most are better off than 
before their migration lo the platform development pai'adigni. 
The reason for this is quite sim|>le: they continue to use 
better engiiieeiing practices on new and existing projects. 

In comparison to the business impact of platform develop* 
ment, the results from using the platform competency mcMlel 
in development are not quite as dramatic. The model has 
primarily been usi^d as a loot for exjjloring the many facets 
of platfcjfrm development. It hits proved to be an excellent 
vehicle for building a shared understanding of what it will 
take to institutloiiaU5!e platform development within an 
organization. Ttie model has also been used as a diagnostic 
tool to identify areas requiring further attention, llius provid- 
ing the basis for developing an overall investment plan. 

Significant different^es exist between the investment plans 
of different organizations. Differences hi the magnitude and 
sequencing of investments in the elements of the compe- 
tency^ model can be traced to differences in an orgaiuzatiotvs 
respective level of software expertise, the rnaiLmty of its 
operatmg practices, and its busitiess constraints. Since each 
organization has a different profile, its roatlrnap for estab- 
lishing a platfonn capability is uniquely its own. In oiu^ expe- 
rience, w^hen organizations stumble in their atjoijtiot) of the 
platfonn development paradigm, the root cause of their dif- 
ficulty^ can be traced to one of the moders elements. 

Tlie feedback that w^e have received as a result of tising the 
competency model with HP divisions has only serv^ed to 
validate tlie model There have been a few minor additions 
to the model, but no signillcant changes. The unanimous 
consensus withiji HP is that each and every element of the 
model is critical. All sixteen elements of the model are nec- 
essary for successful deployment of jjlatform tievelopnient 

Conclusion 

Although nujiveruus pit nluct development strategies and 
paradigms are in use throughout HP, platform development 
is becoming the paradigm of choice within HR The platform 
competency mi:>del discussed in this article captures die 
essence of flP s cumulative exj>erience in plalfonTi develop- 
ment. The model is being used by HP product development 
organisations to understand the requirements and impUca- 
t ions of platfomi development, to guide the creation of m- 
vestnient plans, and to assist in the customization and tailor- 
ing of tJie mode! s elements to fit each organization s 
particiilat^ situation. 

Engineering Perspective 

From an engineering aj id teciuiieai perspective, the platform 
development paradigm is an enable r for technologically 
superior products. The use of a platfonn as the base fcjr new 
prodticts allows enginecjs imd arcliitects to focus their 
efforts on the key, new technical contributions. The use of a 
platform also results in more solid products that aie higher 
in quahty; better mtegrated. aiid ntore consLstenl. Tlus degree 
of robustness results from the continual evolution and im- 
provement of tiie t>latform. 

Management Perspective 

The platform tievelopment paradigni results in a number of 
changes in the way development teams are managed. Since 



new products are developed using botii platform and prod- 
net component streams, management attention shifts from 
an intense product focus to a more integrated and global 
perspective. Managers fmd dieniselves actively involved in 
charting tlieir organization's future, in setting appropriate 
goals and objectives, and in establishing tlie necessary sup- 
porting infrastnicture. Managers through their own actions 
shape how^ their organizadon transitions into new w^ays of 
working within the platform development paradigm. 

In platform development . managers are principal actors in 
Lmderstanding the trade-offs between product and platform 
team needs, commuru eating and making those trade-offs 
explicit, linking them to short-tenn ajtd long-temi project 
and business goais, an<i finally, taking appropriate action, 
lUlimale success is rooted in the ability of the entire man- 
agement lean^ to align its thinking and actions around iis 
instimtiation of the platfonn development paiadigm- Active 
participation by multiple Levels of management, appropriate 
acceptance, and support are necessaiy but not sufficient 
conditions for successful implementation of the platform 
development paradigm. 

Platform development enables an organization to deliver 
innovative, realure-rich, high<iuality, ajid consistent prod- 
ucts on short devf^lopment schedules. It does so tlu^ough 
increased reuse, reductions m per-product testing, and ever 
increasing product quality. Simultaneously, it raises overall 
engineering efficiency, makes it easy to assimilate new engi- 
neers, and improves schedule predictability. These gains 
ultimately translate into reduced development cycle times 
and shorter time to maiket. 

Organizational and Business Perspective 

From asystetnir viewpoiin, the platfotm development para- 
digm is just one of many product development strategies. 
Increased development efficiency and cycle-time reduction 
can be achieved in incremental steps by gradually evolving 
an organization's development competencies. Transitioning 
to ]ilatform development is nontri\ial and is in many w^ays 
analogous to reengmeering the product tJevelopment process. 
So even though changing development paradignts is a busi- 
ness imperative for some IIP divisions, the shift away from 
largely irulependeni kuid autonon\ous development projects 
to collections oi intenelated projects is soinewhat counter- 
culturaJ. Successful adoption of the platfom\ development 
paradigm reciuires aligning Uie organl^Kitional culture, values, 
and rewaitls to suppojl new ways of working. 

There are numerous approaches to adopting platfonn flevei- 
opment. Within HP most development orgtmizations tend to 
follow an incremental, evolutionary approach as opposed to 
a complete, giound-up, or reenguieering aijproach. The for- 
mer supports cmgou^g, new^ product development efforts and 
gradually improves an organization's development capability. 
As svtcli it reduces die amount of change the organiziition 
must assimilate at any given time -and stretches the change 
investment out over a longer period of Ihne. 

Regardless of the approach that an organization selects, 
tliere Jire many common issues and challenges tliat it will 
face and yet each organization mevltably faces some imique 
issues and challenges. liow an org^mization goes about im- 
plementing the capabilities underlying the models indi\idual 
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elements will vary depending or its situation. Each organiza- 
tion needs to work out an implementation plan that fits the 
parameters of its business context. 
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A Decision Support System for 
Integrated Circuit Package Selection 

The package provides signal and power distribution, heat dissipation, and 
environmentai protection for an integrated circuit (IC). The process of 
selecting a package is complicated by the large number of packaging 
alternatives with overlapping capabilities. To handle these difficulties, a 
decision support system was developed. The Package Selection System 
(PASS) combines expert system tools and multiple-attribute decision 
making techniques. The expert system provides a list of technically 
feasible alternatives. The multiple-attribute decision making modules are 
used to rank the alternatives based on nontechnical criteria. 

by Craig J. Tanner 



Two curreiU Ireruls in I he electronic mdustr^* jL^reatly increase 
tJie neeti for ttxilN Uuil assisf in Lhc selection of IC packages. 
The Ursl trend is the emergence of a new llekl of elect run ics 
laiown as "niaiuifactuiingless iruiniifacLiirers" (MLMs). The 
second trend involves tiie iniroduction of competing and 
overlapping lechnologies from subcontract, packaging ser- 
vice?^. This 1 rend complit-ateM the package selection process 
hecanse il creates many technically feasible packages for 
lire decision maker 1 o choose (roni, 

MLMs are only concerned i/idth the design phase of IC manu- 
facturing, and in some cases final package test. All of the 
sijppoil activities dissociated with ICs. such as water fabrica- 
tion, test, and packaging of the IC aie siibt'ontraf tetl outside 
of t.he coit^jany to foundry' services, Tlie tlnished product is 
then sold by the MLM to the end user-, MhMs have several 
advantages over full -service sen^icondnctor companies. They 
can concentrate on doing one flung (design) well and they 
have no t jverbead or R&D costs associaterl with maintaining 
and developing IC manufacturing processes. Because the 
engineers who work for MUVIs aie ty|;jically focused on tlie 
design phase and are not experts m packaging, an IC pack- 
age selection system can be a valuable tool. 

The introduction of competing teclmologies from packaguig 
subcontractoi'S luis made tfie selection process more difricult. 
In the past, there w^is usually one dominating technology 
that filled a particular nlclie. As I nitcd Slates nnd Asian sub- 
contractors have become niore involved in the researcti and 
development of new technologies. son\etimes several pack- 
ages that have similai' technical attributes have been made 
a%^aiiabie to users almost simultaneously: For example, the 
packages sho\Mi ui Table I were released witliin 18 months 
of each other and ^lU were aimed at users who need tliennally 
enhanced surface mount packages. 

Multiple-attribute decision making (MADM) techniques are 
incorporated into the decision suppori system to pro\ide the 
derision maker witli a method for selecting an IC package 
from among technically reasii>le aJteniat ives. The MADM 



Table I 
Competing Thermally Enhanced Surface Mount Technologies 

Technology Company 

Metal Quad Flat Pack OIT 

Micro Cool Motorola 

ASAT 



Enhanced Dissipative 
Quad Flat Pack 

Power Quad I & H 



Anam 



modules allow^ ttie decision maker to rank the feasible alter- 
natives using nontechnical criteria. This teclmique can effec- 
tively address the emerging bend of simultaneous introduc- 
tion of competing technologies from different suppliers. 

System Overview 

The Package Selection System (PASS) contains aU of the 

siil>systems that are typical components of a decision 

support system:^ 

Database mmiagement system fDBMS) 

Model-base management system (MBMS) 

Dialog generation anti management system (D(JMS), 

The DBMS is composed of a datiibase and a management 
system. A databiisc is a file or set of files corttainifig iii for- 
mation needed, generated, or nuuhpulated by a computer 
program. The management system provides the method for 
creating, acces^sing, ami maintaining the datal>ase. Tlie PASS 
database Is an ittfiliffhial ivronls modeL Tliis model consists 
of a set of records iji which each record contatiLs a set of 
fields. Each record represents a t>pe of package. Attributes 
of that package, such as price, are cont^iined in the fields. 
Because the database is an i^SCII file, a separate manage- 
ment system is not required. The rlatabase can l»e updated 
and maintained througli the use of any text editor or word 
processor that is capable of reading and writing ASCII files. 
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The MBMS cmisbts of three models. The fiist model is a 
knowledge-based expert s\'steni. The expert s>^stem is used 
lo detemiine which \C packages are technically feasible. The 
second and third models use the niuitiple-attribute decision 
making techniques known as PROMETHEE and .^P These 
models allow the decision maker to rank the let-hnit^aijy 
feasible alternate es based on pricing and other nontechnical 
attribtii<«>. 

The DGMS is classified as a graphical user inteffare, A 
graphical user interface (GUI) is a means of visually comniu- 

Tucating between the user and (he iippUcatioa The attjibules 
of \isual conmiuni cation include the graphical techniques 
used to commimicaie a concept, a task, a message, the con- 
tents of a screen, or any other interface component. The 
overall look and feel of a GUI is established through the use 
of screens, windows^ com rob, panels, icons, menus, anima- 
tion, and sometimes sound ( wliile sound is not \isual, it can 
be a visual enhancer), 

A sample screen from PASS is shown jn Fig. 1. This screen 
is used for entering ciLStom alteniatjves. Output from PASS 
sessions is presented in two ways: graphically and as an 
ASCI! text fde. The DGMS also contains an online help 
facility. 

The three subsystems described above must interface with 
each other and the tiecision maker to fonn a complete deci- 
sioi^ support, system, A block diagram of the PASS compo- 
te en Is is shown in Fig. 2. The MBMS contains analytical tools 
and heuristic tools. Tlu^ AHP and PROMETIIEE modules are 
mathentatical models while X-PASS employs exjjert heiiiisUcs 
in the form of a knowledge base and an inference engine. 
Decision support systems that use both of these problenv 
solving methods are frequently called hi/brld decwion 
suppofi ,^y steins r 

Multiple- Attribute Derision Making 

Multi[ih' iiftntmh' rltrisitm making {.\LADM) is the study of 
techniques thai i aji \n- used by a decision maker to select a 
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Fig- 1. Package Selection System (PASS) screen used for entering 
custom aJtematives. 

good alternative from a finite ninuher of alternatives when 
faced with conflicting ohjectives. MADM techniques are 
necessary in PASS because X-PASS typically generates mul- 
tijilf alten^atives and a method is needed to evaluate these 
ahemati\'es. X-PASS only makes recommendations base<l on 
the technical aspects of electronic packajEjing, Techtiif al 
attributes tend to overlap packaging technologies- 

Nontec^hnical attributes such as price and deliver>' have 
varying degrees of importajicc baseti on the application tuul 
the decision maker*s objectives for a partictilar integrated 
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Fig. a, P/\HS block rliagraFn, 
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circuit, MADM techniques offer powerful ways of dealing 
with the decision maker's preferences and for ranking alter- 
natives. For this reason multiple-attribute decision making 
has been included in PASS. 

PASS contains two modules for performing multiple-attribute 
decision making. Tlie tiist module uses PEOMETIiEE 
CPreference Ranking Organization Methods for Eiuichmenl 
Evaiuation), The second module uses AHP (Analytic Hier- 
archy Process). 

Including both PROMETHEE and AHP in the decision sup- 
port system allows those users who subscribe to either tli^e 
French or the American schools of thought to take advan- 
tage of that preference. Offering both techniques is also an 
advantage for those users who have no preference or are 
not famiJiar with MADM techmques. These users benefil by 
examining both methods and selecting the tectmitiue with 
which tiiey are most comfortable. The following sections 
contain a brief discussion of the PROMETilEE and j\IlP 
niethods. 

PROMETHEE 

The PROMETHEE technique was presented by Brans snd 
Vmcke m 1985/^ PROMETHEE is an outraiiking method 
and can result in the j>aitial p reordering of alternatives 
(PROMETHEE I) or die complete preordering of alterna- 
tives (PROMETHEE IIJ. The PROMETHEE methods consist 
of three steps: construction of generalized criteria or prefer- 
ence functions, calculation of the miilticriteria preference 
index, and detenuination and evaluation of an outranldng 
relation to give an answer to the multiple-attribute problem 
of uiterest. 

During the construction of generalized criteria, the decision 

maker must assign a preference function, P|,(a,b), to each 

criterion fh, where h — l,2,.,.,k. The preference fimction 

gives the degree of preference of the decision maker for 

selecting action a ratlier than action b. Foiu* meanings are 

given to the preference fiuiction: 

Pi/a,b) = No preference for a over b, f^(a} and fh(b) 

indifferent. 

PhCa.b) - 

Ph(a,b) " 1 

Ph(a.b) - 1 



Weak preference foi' a over b, fh(a) > fhfb))- 
Strong preference for a over b, f|i(a) >> f|i(b). 
Strict preference for a over b, fii(a) >» fh(b). 



For example, if m comparing a $5.00 package a to a $7.00 
package b, the decision maker feels that the S2.00 difference 
between f||(a) = SS.OO arid fh(b) - $7.00 is uisigniiicant, 
then there is no preference for a over b and P|i(ab) = 0. 

The difference between the two evaluations, d Js equal to 
fliW ~ fhCt")' I^h(d) is tlien defined as: 

Ht,(d) = Ph(a,b), d ^ 

= Ph(b,a), d < 0. 

The fimction Hh(d) combined with the criterion %, that is» 
Hii(d) — lHh(d),fh], is called the generalized niteiion asso- 
ciated witli fi^. Brans. Vinke, and Maieschal"^ have developed 
six possible T>i>es of generahzed criteria. ^\Tule other gen- 
eralized criteria can be defined, these six shoidd meet most 
decision makei^' needs. They require that the decision maker 
define only a few pai*ameters. 



HjW} 



"1 



-m 



Fig* 3* Graph of the generalized criterion H,(d). The parameters p. 
q, and d are defmed in the article. 

One of these generalized criteria is defined as follows (see 
Fig. 3): 

Hi(d) - 0, |d S q 

= 1/2, q < ;d| < p 

— ij othei'wise, 

where q is the indifiFerence threshold, which represents the 
largest value of d below which the decision maker considers 
there is indifference, and p is a strict preference threshold, 
which represents the lowest value of d aljove which the 
decision maker considers there is strict preference. 

Tlie second step of the PROMETHEE method is to calculate 
the multicriteria preference index for each alteniarive over 
all criteria. The preference index is defined as:"^ 

k 
ji(a,bj = Yw,A(a,b), 



where 



k 



= 1 



and 

Q < n:Ca.b) < L 

This uidex is the memi of the values of the k preference 
f mictions. W^ is a weight associated with each criterion, 
A weak preference of a over b is denoted by the value of 
]T(a,b) being close to zero. A strong preference of a over b 
is denoted by the value of .T:{a,b J being close to one. 

The third and final step of the PROMETHEE method, deter- 
mination and evaluation of an outranking relation, requires 
that poshive and negative outranking flows be deterauned 
from the nmhicriteria indexes. The posiUve and negative 
flows aie defined asr- 



* + (a) - Y.'^^^^'^ 



be A 



and 



(a.) - ^ rtCb.a), 



be A 
where A is the set of possible actions. 
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The following mtes can then be used to goterate a paitial 

preordering oflhe alternatives. P means *1s preferred to," 
I means "is indifferent to," and iff means "if and only if/" 

• aP*b iff 0^ia) > #*{b) 

• al*b!ff<^-Ca) = «l>-(b) 

• ap-biffas~(a) < 0^(b) 

• al'biff^'Ca) ^ ^'(b). 

The outranking relationship is then constructed from these 
ruks: 

• a outranks b if aP*b and aP"b or aP^b and al~b or al"b and 
aP^b, 

• a b indifferent to b if al+b and aJ"b. 

• a and b are incompamble otherwise. 

Analytic Hierarchy Process 

AHP was developed by Thomas I*. Saaty in the 1970s. It is 
based on a set of axioms developed by Saatj"' and published 
ill a paper by Marker aiid \argas in U)87.*^ A good mathemati' 
cal analysis of these axioms can be found in reference 7. 
The four axioms were paraphrased by Harker as follows. 

L Given any two aJteniatives J and j out of the set of alter- 
natives A. the decision maker Is able to provide a pairwise 
con^parison ay of these alternatives undt^r m\y t^riterion c 
fron^ the set of criteria C on a ratio scale that is reciprocal, 
that is, 



1 



for all LJ e A 



2. When comparing any m^o alternatives ij E A, the decision 
maker never judges one to be infinitely better tiian another 
under any criterion c, that is, ay ?^ ^ for all i,j e A. 

3. One can formulate fhe decision problem as a hierarchy. 

4. All criteria and alternatives that impact the given decisioti 
problem are represented in the hierarchy, thai is, idl expecta- 
tions must be rej^reseiited (or exckidtHl) in terms of criteria 
and alternatives in the slnicl lire and be assigned priorities 
tliai are compatil>le with expectations. 

Using these axioms, decision applications of AHP can be 
earned out in two phases: hierarchy design and evaluation. 

The first phase^ hierarchy design, involves the estimation of 
weij^hts for each criterion that is used to rank alternatives. 
Mosl decision makers are facetl with two tyijes of criteria: 
quantitative and qualitafive. For criteria based on quantita- 
tive data such as cost or si:^.e, die weights can be estimated 
by normahzing or inversely normalizing the comparison fac- 
tors for each column of alternatives such that the weights 
sum to 1; 

a^: 

for all i,j = l,2,...,n. 



n 

I 

k-l 



W 



For criteria biised on qualitative data, a relative weight ma- 
trix can be construcled using Saaty *s scale of measurement*^ 
(see T^ble \ly 

The positive reciprofaj matrix constructed asing a verbal 
scale techni(|(ip may (*ontain errors in judgnierit* C ohttnn 
normalizaiioti of this type of data would produce dLfferent 
results depending on which column was chosen. 



Table tl 

Saatv's Scale of Measyrefnent 

Value Definition 

1 Equally important or preferred 

S Slightly more important or preferred 

5 Strongly more important or preferred 

7 Very strongly more importaiii or preferred 

9 Extremely more importani or preferred 

2,4,6,8 Intemiediate values to reflect compromise 

Reciprocals Used to reflect dominance of the second 

alternative o%'er the first 

Saaty s eigenvector method^ is one technique for generating 
weights that eff ecti%ely deals with these errors. Tile eigen- 
vector method results in final weights thai are an average of 
all possible w ays of comparing the alternatives. The w^eiglits 
from the eigenvector method are calculated by raising the 
matrix of alternatives A = [ay] to increasing powers of k 
and then nonnalixing tlie resulting system:"* 



w = lim 



A^e 



where e is a column vector consisting of ail Is and e'^ is the 
transpose of e, \^Tien w converges, tlie process is complete 
and a consistency irtdex can be calculated that is an indica- 
tion of the magnitude of the errors in the matrix. 

After construction of the luerarchies, the second phase of 
AliP is evaluating the hierarchies to make a decision. Evalu- 
ation tjegins with constructing a final hierarchy of the pair- 
wise comparisons of the criteria. Because the crireria are 
not ujiually equally Itnportaitt or quaint ifiable, Saaty s scale of 
ineastirement mvX eigem'ector approach are well-suited to 
deveiopmg the weighiJB for ranking tlie importance of the 
criteria. The order of preference can then be determined by 
summing the relative priorities by weighting them with the 
overall priority of the given criterion. 

Using PASS 

The Package Selection System is a Microsoft Windows'*- 
based ajiplication. It was developed using Micrt^soft's Visual 
BASK, version 2.0. Visual BASIC' is a programming metluKl- 
ology that allows tjie developer to create programs that can 
take advantage of the Windows graphical user interface 
(Gill). Visiuil BASIC applications have the ovcraO "look and 
feel" of professional Windows applications including pidl- 
down menus, buttons, check boxes, scroll bars, le.xl boxes, 
and icons. Visual BASIC programs can take advantage of 
other Windows features including multiple-document inter- 
face (MDI}j dynamic data exciiange (DDE), object linking 
and embedding (OLE), and dynamic hnk libraries (DLL). 

A typical PASS session is run in the following manner 

1. Select iechnically feasible alternatives using tiie expert 
system, X-PASS. 

2. Start the multiple-attribute decision making module by 
clicking on MADM. 

3. \\\\)\\\ the nimiber of criteria and alternatives. 
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Package Selection System 
(PASS! 





^^ 



^^^^^1 ^^^^^1 ^^^^^1 ^^^^^1 ^^^^^1 ^^^^^1 



Fig. 4. liierarchy c)f Ihp irmjfir 

PAkSS modules. 



4. Select the MADM tool (AHP or PROMETHEE), 

5. [nput the alternatives. Usually alternatives are selecleti 
from those suggested by X-PASS but the user is free to 
selet;t other alteniatives or cleliiie a custom alternative. 

C. Input the criteria. Several criteria are suggested by PASS 
for the purpose of raiikiiig altemaiives, but the user is free 
to defme custom criteria. 

7. Input the infomiarioii requirt^tl to describe the tfecisioji 
maker's preferences. 

8. Tell PASS to evaluate alternatives by clicking on Evai from 
the PASS window menu. 

PASS contains IS sepajate modules for accomplishing this 
task. Tiie modules ai'e used for inputting data, selecting 



criteria and alternative's, creating custom alternatives, dis^ 
playing results, and interfacing with other Wmdows applica- 
tions. The hierarchy of the m^jor PASS modules is sho\\m in 
Fig, 4, 

PASS can be start ed by clicking on the PASS icon or by typing 
in the proper patfi and Pass.eKe in one of the Windows Run 
screens. Diuing staitup, a welcome screen is displayed. After 
a brief paiLse, a module selection screen Ls displayed. From 
this screen the user caji choose au expeit system ronsuita- 
tion or select muljiple-at tribute decision making. 

Selection of X-PASS causes the expert system module to 
stait. The knowledge base for X-PASS is aulomatically 
loaded. The X-PASS screen is showii in Fig. 5. Tlujs form 
contains four control buttons: Go, Restart. Stop, and CanceL 



File Help 



n Re^tarl j S^lop 



" "-'" Welcome to X-PASS The eXpert Package Selection System ---'■'*-- 

This eKpeit system will help you to select integrated circuit (!C) packages which are 
technicatly feasible alternatives foi the proposed IC 

X-PASS will ask you a series of questions to help deteimine feasible alternatives. If 
you are unsure of an answer jpou may press "Unknown" When pressing "Unknown", 
X PASS will answer the question for you, using variables which allow for the broadest 
range of feasible packages. After completing the initial consultation, you should 
determine values for all "Unknown" questions and then repeat the consultation. 

If you are unsure of why X-PASS is asking a particular question you may press '^hy". 



Should the selected packaging technology have the ability to use 

external heal sinks? 



Select: any item. 



Why? 



Unknown 



CF 



OK 



Cancel 



Restart consultation 



Fig. 5. X-PASS form. 
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The X-PASS soreen also contains three response buttons: 

Why, Unkfiovm. and OIC 

Go is used to be^ a coiisultatioii, Restan continups a con- 
sultation that was iiiad\'eit.ently abort€*d. Slop ends a con- 
sultation but preserves the ciunent knowledge cache. Cancel 
ends the consultation immediately and clears the knowledge 
cache. 

A user can respond to a question asked by X-PASS wiUi Why. 
Unknown, or OK. A response of Why causes a message to appear 
that explains why the exj)en sv^leni needs that particular 
piece of information. Sel€^cting Unknovyn forces the system to 
pick an aJiemative that is the (east restricti\'e in terms of 
elmutiatjng altemadves. It also assoc^iates a low certainty 
factor with that choice (a certainty factor is a niiniber be- 
tween and 1 representing the decision makers ctmfidence 
in an answer given in response to a quesl ion from X-PASS). 
Selecting OK enters the users highligliied response into die 
knowledge cache. 

.'Uso on the X-PASS form, certainty factors can be entered in 
tlie box labeled CF, and oilier knowledge bases can be entertHl 
into X-PASS through the use of the file menu. This powerful 
feature iUlows the X-PASS database to be modified by any 
user It also allows X-PASS to be used as tm expert system 
shell for other, nonpackaging-related jjrobiems. Feasible 
alternatives thai are detemiined by a consul at ion witJi X- 
PASS are sa%'ecl in an ASCII file for optional use by the 
MADM modules. 

Che king the MADM button on the module selection form 
initiates the process for using the multiple-attribute decision 
making toc^ls. The firsl fomi in the MADM module {Fig. 6) 
allows Ihe user to input the number of altemalives and c^rite- 
ria. Tlie AllP or PROMETHEE technique is also selecled l>y 
using this form. A list l>ox on the form shows the dec*ision 
maker all of the standard criteria supported by PASS. Tln^ 
user also has the option to check the box labeled Use X- PASS 
Alternatives. Selecting this option enters the feasibk^ attema- 
tives determined l>y the most recent X-PASS consultation 
into working memor>' Otherwise, the decision maker can 
tyf»e tlu» number of alternatives and criteria into the text 
boxes at the righthand side of the fonn. A maximum of 20 
alternatives antl 2fJ criteria can lie usod. This limitati*>n Is a 
resuit of tlie way in wliich Visual BASIC han tiles large 
airays. 

Tlie remainder of the MADM Innns are activated by using 
the menu on the m^iin PASS fonii. Mo8t of tjie data entr>' for 
PASS Ls self-explanat(ir>^ and a help facility is i>rovitled to 
assist in data entiy. 



Opel 
P Promethee 

r AHP 

F Use X-PASS AlternaHves 



^1 



fi 



Possible Criteria 



Price ($1 
Design (Wkt) 
Lead Time (Wks) 
Overhead (hrsj 
Somcmg |tt) 
Qudlit^P 
Rework 
Prototyping 



Alteinatrves 
I Cfitaiia 



□ 
□ 



Enter 



Fig. 6. Inir.iiil MADM fomi. 

Entering Criteria for AliP and PROMETHEE 

Criteria for AHP atMi PROMETilEE aie entered in different 
ways. Tlie criteria ii^inil ntodules are activated by selecting 
CtTt from the main menu. For AHP, tw^o forms are used to 
enter criteria. The first form (Tig. 7) is for alternatives selec- 
(ion ;ind contiiins a combination list box labeled Criterii, As 
tfie name implies, it is a lisi of the standard criteria sui>- 
ported by the packaging selection system. After aU criteria 
are entered into working memory, a second screen is acti- 
vated. Tills screen, shown in Fig, 8, allows pairwi.se compari- 
son of the criteria, biLsed on Saaty s scale of nieasurement. 

Comparisons are made by entering a number from Saaty s 
scale in the matrix in the upper leflhand comer. Tliis causes 
a row to be comparetj witli a c*( jlunui. Tlic* reciprocal com- 
parison is automatically entered into the proper cell After 
all cfnu[>aris(>ns have beeu made the weiglvts and consistency 
index can he displayed by using the Eval button. 

A consistency index greater than 0.1 Indicates liiat modiiica' 
tions to the matrix may need to be made. Tlie Reset liutton 
cli*ary the weights aitd consistency indf^x luit lea\es the 
matrix mtact. This is useful if only slight modifications to 
the matrix are desired. Tlie Clear but Ion clems the matrbc as 
well as the weights and c^onsislcMicy index. Pres.sing Exit 
enters all data into \vf)rk'ing memory and returns the system 
to the main menu, Saaty 's scale is shown ui a hst box at the 
lower lef1i\ajid comer of the fonn. 



From the "Criteria Combo Box" 
Select Cfiteira K umber: 




t.edd Time (Wksl 
Overhead thrsl 
Sourcing [U} 
Qualily 
Rework 
Prototyping 



Fig, 7. Selertinit allfmialiveii in 
AHP 
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CI CZ l€3 IC4 |C5 




CI = Price ($) 


1 00 

1 1.00 


C2^0edgn{Wksl 


C3 ^ Quality | 


1.00 


C4 - Lead Time 


C5 = Rewofk 


' ^ 1.00 









Contfob 



Enter 



Weights and Cofisistency Index 




WeigMs 



CI 



C2 



C3 



C4 



C5 
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EontisleiK^ IndeM 



Evaf 



Reset 



EXIT 



EMit 




Cbar 



Saaty's Scale 



1 - EqudMy impoflant or pFefeied 

3 ' Slightly more importafit or prefer ed 

5 - Strongly more important or preleied 

7 - Very itrongly more important or pretered 



AHP 



Fig, 8, Making pairwlse rompari- 
R nil ft in AHP. 



Enleriag criteria for liie PROMETHEE technique is a three- 
step process. The PKOMETHEE form is shown in Fig. 9. 

The first step is selecting a criterion from the list box in the 
criteria section of the form. The criterion is entered into 
working nienioiy by pressing OK. A range of valoes for each 
of the criteria corresponding to the preselected alternatives 
is shown in the raiTge list hex. 

The second step involves selecting a preference function by 
pressing one of the six buttons located in the upper lefthand 



conier of the form. UTien a preference fimction is selected, 
a graph of the fi^mction showing the parameters appears in 
the screen to the right of the buttons. For the form shown in 
Fig. 9, preference function four (P4) has been selected. 

The third and tlnal step is to enter the appropriate v^aliies for 
the paranieter(s) in the text boxes located in the parameters 
section of the fonn. The listing of the range of data is useful 
for this step, AU data is entered into working memory by 



PI 


P2 


P3 


P4 


P5 


P6 




Enter the value lor q in 'Parameter 1". Enter the value foi p in 'Parameter 2'. 

Enter the weight for criteria 1 . then press 'Record Ciiteiia'. Weights will be normalized 

over all criteria. 
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Fig. 9. Entering criteria in 
PRO.METHEE. 
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clicking on Record. This process is repeated for aO selected 
criteria 

PASS Output 

(Jutpui from PASS is presented visxiaUy and interacth'e!y 
while using the sofhvare. ASC*II files are also generated: 
ihese can be imported into reports or other applicadons. 
Ttie outptit from X-PASS Is a list of tecimically feasible alter- 
natives. With each alternative a confidence factor is reported. 
The confidence factor ranges from 20% to 1009^3 and is based 
on the nunnber of questions answered as "unicnown," The 
output from the MA.LLM modules consists of a mnking of the 
alternatives and tiieir associated weights. A sample of the 
ASCn output from an AHP session is shown in Fig. 10. 
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Cycle Time Improvement for Fuji IP2 
Pick-and-Place Machines 



Some of the major enhancements are eliminating head contention, 
reducing or eiinninating nozzle changes, supporting user-defined nozzles, 
supporting large nozzles for holders 1 and 3, and being able to define 
multiple part data for a given part number The cycle time improvement 
exceeds the original goal of 5%. and the result at one surface mount 
center was more than 1 B% over hand-created and optimized recipes. 
The solution helps both the high-volume and the high-mix centers. 

by Fereydoon Safai 



Reduction of placement cycle time in aii assembly line is 
one of the m^jor goals in a surface mount shop. It is more 
important in a higii-vt>lunie sliop than in a higti-mix shop 
because most of the assembly lijne is spent in part place- 
ment. The reduction of placement cycle tin^e at high-volume 
centers would have a liigtier impact than at our hi^i-mLx 
centers. 

HP o^vns many Fuji 1P2 machines at our surface moimt ccn- 
terSj one on each hue. The Fi^i 1P2 inachine is a One-pitch 
pick-antl-place machine capable of placing parts from reel, 
stick, and waffle feeders. It is considered a general-purpose 
pick-ai^d-place machuie because of its ability to place a wide 
range of parts- It h;is two heads, which alternately j:tirk up 
parts fioni the feeders and place them on rhe ]:tanel. Eacli 
head has rv^'o holders^ one with a flxed nozzle and one with 
an automatic nozzle. A fixed noiizle must be mstalled into 
tbe fixed holder before ihe machine starts placmg parts. An 
auiomatic nozzle of size S, M, L, or LL can be picked up by 
the automatic holder from a nozzle station. The nozi^le station 
has six noKxles: one S nozzle, one M nozzle, two L nozzles, 
and two LL nozzles. 'I 'he S and M nozzles are shaied betw een 
the tw^o automatic holder's of tlie two heads. Each automatic 
holder has its own L and LL noiizles; they are not shaied 
between the two automatic hokiei"S, 

Since the S and M nozzles are shared betw^een the two auto- 
matic holders, il is impoitimt diat flie sequence of placement 
be arranged so thai I he Iwo automatic holders do not require 
the S or M nozzle at I he same time. If they do, depending on 
lite particular Fuji IP2's firmware, either one side will halt 
imtil the other side fmishes its placement and releases the 
nozzle, or the 1P2 software wiM crash. In either cajse> head 
contention is createci, which is a problem for IP2 placement 
macliuies. 



The Fuji IP2 machine has slot numbers 1 thiough *17, 51 
through 87. and 101 through 110. Slots 101 tlumigh 110 are 
used by the waffle unit. If the waffle unit is installed, it inter- 
feres with the niachine and makes slots 1 through 'J inacces- 
sible. Slots 1 to 37 and 51 to 87 can be used for mounting 
eiUier reel feeders or stick feeders. Slots 101 to 110 aie used 
for^ whiffle feeders. 

The 1P2 macliine has a nuhibef Df of constraints. Only one of 
the automatic holdei^ (holder 1) can access waftle paits froni 
slots 101 to 110. Tiiia holder can also access slots 4 to 37 if a 
waffle miit is installed or slots 1 to 37 if no waffle unit is 
ifisialleti. The other automatic holder (holder 4) can access 
slots 51 to 87, One of the fixed holders (holder 2) can access 
slots 4 to 37 (not I to 37) ajKl the other flxed hokler (holder 
3) can access slots 51 to 84 (not 51 to 87). The two flxed 
holders 2 and 3 can pick u^j paits up to 3.5 mm in height and 
the two autouratic holders can pick up paits up to 10 mm in 
height. 

The Problem 

The issues related to the Fiyi rP2 are in two categories. One 
categoiy consists of the issues that reduce the placement 
cycle time, such as use of the next de\1ce, use of multiple 
part data, the ability to assign a part to botli sides^ and the 
ability to assign placements to holders based on reference 
designators- Ttie other categoiy consists of the issues thai 
make the machine perfonn correctly. The main item in tJiis 
category' is head contention. If head contention occurs, for 
certain IP2 flniiware the machine halts and the user must 
change the sequence of tJie recipe to run the machine again. 
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The Methods 

hi this set'tion, we desc^ribe oiir solution for each issue le- 
latecl lu the Fiyi IF2 machine. This inclucies eilniiiiation of 
head c-ontenrion. support of the next device meehanism of 
the lP2v support for user-defined nozzles such as a modified 
medium nozzle for holders 2 and 3, use of multiple part data 
for a part number, and assignment of a pan to btitli sides of 
the machine to acfiieve a better head balance. 

Our general solutton is as follows: we assign placements to 
holders to balance the Uiad among die four holders. In the 
(>roc;ess, we consider first die plat ements that luive slots 
already assigned. This is liie case wiien the pari numbers 
are in tlie input setups. Tlien we assign slots to those plact^ 
ments that do not Ymve slots in the input setup. Tliis general 
solution is used for both setup and sequence modules. In 
the sequence module, all the placements have fheir slots 
assigned. 

In tiie following sectioas, we describe many issues which 
are considered when assigning placements lo holdens. Oiu* 
solutions have been incorporated in setup and sequence 
generation modules for the Man-Link recipe generation 
system, which is used by all HP siul'ace moimt centers that 
have Fuji 1P2 machines. Other Man-Link ciihaiiccmenLs are 
discussed in the article on page 84. 

EHminattng Head Cotitention. Head contention occurs when 
holders 1 and 4 iiet^(i tlie smne nozzle (S or .M) at the same 
time. At this time, tlie machine behaves differently depend- 
ing OJi what Onnwcue it has. Machines ha%Tng older versions 
will stot> lutti tile user must edit the recipe to eliminate tlic 
head contention, hi newer versions, die holder that n(*eds 
tiie S or M nozzle must wait until ttie other holder finislies 
its placements and leleases the S or M nozzle. 

Ijt our solution, we do not assign parts requiring the S or the 
M nozzle lo t>oth holders 1 mi<l 4. We iLssign eaf^h nozzle only 
to one of them, deiieruling on t fie loads of the holriers. This 
way, Ihe nuK'liine in ihe woi^t t^ise will t>laee ;ill such pans 
wit ti one sitle. This winiki tiot be w^orse than Uie case in 
which one side nuisi wait until the other side finishes. 

As an example, assume Oiat there are tifvo parts, each rttquir- 
ing the M nozzle iuid each having 10 pla^'cnicnts. Further 
assume thai Jioldcr^ 2 an(J 'J do not have any nozzles ahached 
to them. Assigning both of these jjiuls to one sidt*. say to 
holder 1, would not be worse than the case in which one 
part is assigned to holder 1 and the other part is assigned to 
holder 4. Using our solution, Mjui-Link assigjis holh parts to 
one side, say holdfT L In this case, Ihe inaehine will go back 
and hjrtli aiul place one pati at a tiiue for total of 2(1 roui\d 
trips. If one p^ul is assigneci to liolder 1 *uul the other is as- 
signed to holder 4, and if llie machine lias the latest firm- 
w^aie. liolder 1 will ])ic k up the .M noz/le arul go back and 
forth aod make its lU placements. Wluh^ holder I is i)lacing 
parts, holder 4 must Wiiil until holder I releases mid replaf;(^s 
the M nozzle. At that time, hfjlder 4 will pick uiHlie M nozzle 
arid goanrl make its 10 plaecnienis. The inarhiiie has lodo 
two nox.zle chatiges ftjr caeh hoard, lioih af which iuv un- 
necessjux Our solution docs iiof nwil any tu>zzie changes in 
this pailiciilar case, thereby saving 10 to 15 seconds. 

Our solution not qnly ehminates the head content ion, but 
b^ts the additional lu-nefit of eliminating uozzlc changes be- 
cause of head conteiiliou. In die past, users would lujt assign 



to the IP2 parts requiring S or M nozzles because of the head 
contention issue. This caused the 1P2 to be undennilized. 
N'ow users can a^ign such parts to the IP2 wlten necessar>' 
and tliis will help to reduce the overaO Q^cle time of products 
lieing built. 

Using Slot Uitk (Next Device), ^ith Fuji IP2 machine it is pos- 
sible to place multiple feeders containing the same part on 
the machine and have the recipe reference one of the slots. 
When the parts from tiiai slot are depleted, the macliine 
goes automatically to the next slot that has that part and 
continues placing. 

This slot link mechanism is \'ei> heipfiil for waffle partB. 
Since the wafHe feeders do not take many parts, the operator 
frequently has to stop the rnac:lune and replenish the parts. 
If a recii>e uses only one fine-pitch pan from die waffle unit^ 
all 10 waffle feeders of tlie IP2 can be filled at once antl all 
of these parli^ can l)e used before the maciiine needs to be 
Slopped to refill tliat part. 

The meciianism provided by Man-Unk is its follows. The user 
enters, in an uiput setup, the slots diat a particular part is to 
occupy and then Man- link takes over and creates the recipe 
ai^propriately. As an example, if a part is assigned to all 10 
slots of the waffle t>ack unit, w^e would have a recipe con- 
taining llie slots ai^d slot links (next devices) shown in Tcitjle I. 

Table I 
Slot Link (Next Device) Example 

Part Numtier Slot (Device) Slot Link (Next Device) 

Part 1 101 102 

Part 1 102 10;i 

Fail 1 103 104 

Part 1 104 105 

Fart. 1 105 100 

Fart 1 106 107 

Part 1 l«f 108 

r>an 1 lift I0f> 

Parti 109 110 

Fart 1 UO 101 

As shown in Table I, a cinnilar link is created between slots 
101 through 1 10, The tiextslot for slot 101 is 102, the next 
slot for slot 102 is 1(J;3, m\6 so on. The last slot, slot 110. is 
linked to ^slot 10 L the Oi>*t slot, to (Teati* a circuL'u* link. The 
oi)crator will fill all ten trays wiili pajl 1. hi the recipe for 
this part, slot 10 1 is referencetL The machine stalls pie king 
up parts from slot 10 1 aiid places them on the bomd until all 
parts an* used up. Then the niacMne will go to tlie next slot, 
whieh is sl(jt It)2. and stint placing parts. This will continue 
until parts from all ten feeders aie depleted. Then the 
inachiuc will st<)[>. tiie operator will till all ten trays, and 
tht^ cy( le will begin again. 

User-Defined Nozzles. Holders :i iuid -i takt* a fixed no:£zk\ 
The nozzle sizes t hat Fuji supt)lies for these two holders are 
S :unl M. One of our surface ruoniil siles ereati'd a larger 
iuy///Av tor tiit^st* two holders. This (\\[)faHled Ihe capability 
of tlte machine so that it can pick up as many as four larger 
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parted while the originaJ machine can pick lip only two larger 
parts. Although the nozzles are lai'ger, the FH^ji n^achines 
requite thai lliese nozzles still be called S or M iri recipes* 
Another issue is thai tiu^se laj^ger S and M nozzles must be 
distinguisheti froni llie S and M nozzles Uiat holders 1 and 4 
can pick up from the nozzle station. For thes^& reasons, we 
provide a mechanism that allows the user to define any 
name for a particular nozzle and tlien map it to one of the 
Ptyi-recognized nozzles (S, M, L, LL). 

Our mechanism is as follows. The user defines what nozzles 
are installed in the nozzle station on the niaf^ltme and what 
nozzles are installed in die two fixed holders. The names of 
tlie nozzles are user-defined. We have pro\ided six coidlgu- 
ration parametei's to name the six nozzles in the nozzle sta- 
tion and two configuration parameters to name the two 
fixed nozzles, as shown in Table 11. 

Table II 
ConfiguratiQO Pararneters to Name the iP2 Nozzles 



Table III 
Nozzle Sizes Used at HP Surface Mount Centers 



Configuration 
Parameter 

LEFT LL NOZZLE 



LfFT LMOZZLE 



M_NOZZLE 



S N022LE 



RIGHT L NOZZLE 



Description 

The left. Ll^ nozzle in 
the nozzle station 

Tlie left L nozzle in 
the nozzle station 

The M nozzle in the 
nozzle station 

The S nozzle in the 
nozzle station 

The right L nozzle in 
the nozzle station 



RIGHT_LL_NDZZLE ^fhe rigtU LL nozzle tn 
t!ie nozzle station 



H0LDER2_N0ZZLE 



HDLDER3_ NOZZLE 



The nozzle in fixed 
holder niunber 2 

The nozzle in fixed 
holder niunber 3 



Possible User- 
Defined Nozzle 
IVames 

LL, ML, XL 



M 

B 

h 

LL, ML, XL 

S, M, Modified 
Medium 

S. M, Modified 
MetUtim 



In Man-Link, a part number is Linked to Ftyi part data. Ln the 
part data, tlie user defines a nozzle (like Modified Medium) 
and then luiks this nozzJe to a Ftyi nozzle, wliich nuglit be M, 
We tise the tiser-defincd nozzles of each pait to assign them 
to nozzles of the machine, which are also specdicd by the 
tiser. 

In Table HI, the actual dimensions of the different no^es 
used at different HP surfaee mount sites are listed. 

Multiple Part Data for a Part. From tlie Uisrussion of the pre- 
vious sertitjn, it is ob\1ous that a pml miglu l>e ijjcked up 
successfully by multiple nozzles. For example, a pat1 niiglir 
be picked up by botli Modified Medium aitd ML nozzles. 
Their nozzle diameters are very close: 6 mm and 7 mm, 
respectively. For this reason, we have provided part data 
preferences stich that the tiser cati decide which pai1 data 
(£ind in turn w^hich nozzle) is the best for picking up a pai1, 
and ^ive it the Itighest preference. Tlie user can then provide 
additional pait data^ using o titer nozzles sizes, for tliat part 
with lower preferences. Our software wiU try to use the part 



User-Defined 

Nozzle Name 



M 

Modified 
Medium 

L 

LL 
XL 



Fuji 
Nozzle 

Name 

S 
S 
M 
M 

I. 
LL 



Holders 
1,2,34 
1,2,3,4 
L2A4 
2,3 

1,4 

1,4 

14 



Nozzle 
Diameter 

(mm) 

LO 
L3 
2.5 

ao 

4.0 

7.0 
1 0.0 
15.0 



Light Ring 

Diameter 

(mm} 

21 

21 

33 

33 

71 
71 
71 
91 



data with the highest preference, but it will use other part 
data if it will improve the balance among the four holders. 

A user who has multiple part data defined in the system 
might still waitl to use the part data widi the highest prefer- 
ence. We have provided the configuration paraineler MULTL 
PART_OATA with values of VES and NO so the user can choose 
whether all part data for a part should be considered orjust 
the pan data wit h tiie liighest preference. 

Assigning a Part Number to Both Sides of a Machine. Occasion- 
ally a product will have apart nimtber that constitutes more 
than 50Xj of all the placements for the 1P2. We have seen 
cases in which there is only one part assigned to the IP2. 
If only one ps:irt is assigneti to tiie machine^ one of Ute heads 
w^ill be busy placing parts wfiile the other head is idle, doing 
nothing. P^or this reason, Matt-Link allows the user to dupli- 
cate the part on both sides of the machine and the software 
will split the reference designators of tltat part between die 
two heads to balance the load. 

If a machine is used in a high -volume shop for such cases, 
multiple feeders of the doniinant part can be placed on each 
side of the machine to take advantage of the splitting of the 
reference designators descnbed in this section and the slot 
link (next (ie^lee) feature described earlier 

Assigning Placements to Holders bv Reference Designators. 
Ai>stime tlvai there is only one pait assigned to an IP2 for a 
product iuid it is placed on the right side of the machine, 
where holders 1 and 2 are located. F\iriher assume that the 
part requires im S nozzle, and an S nozzle is fixed into holder 
2. [n litis case, it is reasonable t hat t be referetice designators 
of the part be splil L>etweeri the two holders, 1 atid 2. This 
will speed up the placement cyi^le time since the right head 
can pick up two parts and then go and place both of them. 
This is what our software will do. It attempts to split the 
placements among liolders such that tlte load is bidanced 
among all holders. 

Of course, if that part is duplicated on the left side of the 
ntachiite aiKl an S nozzle is placed into holder 3, then three 
holders would be picking up parts and placuig. This way 
both sides of the machine would be used. 
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Minimizing Nozzle Changes. Beducing nozzle changi^ is an- 
other miportaiit task. It was siioim earlier that eliminating 
head contention also reduced the nozzle changes by two» 
Each nozzle change takes five to sev^n seconds. In a Kigh- 
volome shop, it is important that the number of nozzle 
changes be minimized. 

Since holders 1 and 4 have their own L and LL nozzles, it is 

importani to assign ali parts requiring the L nozzle to one 
holder and the parts requiring tlie LL nozzle to the other 
holder The imbalance between such holders deienmnes 
whether to assign parts requiring L and LL nozzles to one of 
these holders. For example, if tliere are parts requiring the L 
nozzle and their iut*U placements are much more than the 
parts requiring the LL nozzle, then we assign the parts 
requiring tlte LL nozzle to one side and the parts requiring 
the L nozisle to both sides. In this rase, we create one nozzle 
change on the side contajnjng the parts \\ith L and LL 
nozzles. The decision to assign the parts with the L nozzle to 
botii sides of the niaciiine or to a single side is made so as to 
minimize the total placements including the nozzle change 
cost. 

Since the nozzle change time is not a constant time, we use 
a configuration paran\pter to set the cost of nozzle changes 
in tentis of placements. The name of the configuration 
parameter is NDZZLE_CHANGE_COST. It has die default vahie 
of 2.5, This means tJiat each nozzle change takes as long as 
2.5 placements. 

Prerotation and Re scan. Fuji pan data has two fields called 
preroUiilon and rcsniti. If the prerotation field is set, the 
pan nuts I be jj re rotated hefore tiie camera can look at it. 
Thereforej ihe Iieatl thai performs sucli placements can only 
pick up one pai1 inst eati of two, there Liy slowirtg down the 
n^achivie. We keep track of such [jarts since they affect the 
Iciacl baUmce between the holders. 

The effect of the rescan is Iht^ same as thai of the prerota- 
tion. If the resciin fi<itl is set for a [jart, the head that pi<'ks 
up such parts can only pick up one part, and not two. Again, 
we keep track of sucli parts aiu! take them into accoimt for 
load balancing iunong the hoiders. 

Slot 34 and 54. Because of the constTuc;tion of the Fiyi 1P2 
machine, iiarl [ilacemenls from slots M (by holder 1 ) atid M 
(by holder 4) have the fastest cycle time. Therefore, it Is 
important that the high-count p^uls are tissigned to titese 
two slots, if 1 he parts are assigned to holdt^rs 2 and 3, this 
does not hold. For holder 2, a pai1 at slot 37 has the fastest 
cycle time, and for holder 3, it is slot 5L 

Using slots 34 and 64 for high-count parts has the drawback 
of potentially w^isting one to two slots, so if feeder space is 
at a premitJm this rnechanism is not appropnatc. However, if 
feeder space is not an is^sue, the cycle time can be reducetl 
by using this uu^chaitisnL This is especially imporlajit for 
high-volume sjiops. We have provitk^d a cortfiguration pa- 
rameter for users to choose whether to use this feature. 

Slot Numbers. The center-to-center distance of the two hold- 
ers of t-acl^ htw! is 63 mm. Tlie pitch of the feetler Inink is 



21 una The festest pickup occurs when the parts for two 
placements made by the two holders of a head are 3 slots 
away fi-oni each other. 

After the assi^mient of placements to holders is completed, 
we order the placements of each holder by slot number. In 
general, it may help the cycle time to pick up two p^s with 
eacti head. 

X and Y Coordinates of Placements. Another &ctor that can 
help reduce ihe cycle time is the distance bet^veen twxi 
placeinenis on the panel. For example, if both htJlders of a 
head are pickitig up two parts, it will be faster if the two 
placements are close together on the panel Therefore, after 
we sort die placements of each holder by slot (as explained 
above) then we order them by their separation on the panel 

Results and Discussion 

One HP surface mount center was editing recipes to balance 
the load among the four holders. Ai\ engitteer was doing tJiis 
task. This was critical because of the high \'ohmie of some 
of tlie center's products. Wien our solutioit was available, 
the center tried it and got a very good result Our solution 
was more than 16% faster tJian the recipe that was hand- 
optimized by iui engineer. We should note that when this 
project was fimdetl 1he goal was to achieve 5% ittiprovement, 
but in all cases we have exceeded this initial goal. 

As explained earlier, one of the m^or Issues w^as head con- 
tention. Fomierly the user had to edit the recipe to get 
around this problem. As a result, many useis were not 
assigning certain pails lo the IP2. This tended lo increase 
the cycle tinte ot their component placement niachiries 
because it increased tlie load on the fast n^achines. Since we 
have eliminated the hear I contcntit^n issue, itsers have moved 
tnore parts to thetr IP2 machines and have increased their 
throughput. 

At other centers, the next device mechanism has saved 
0,5 hottrs per sliift on each line. 

For contract manufacturing, especially for high-volume 
productSt tlie cycle time reduction can provide im important 
cotnpetitive advantage. We can create recipes witJi oiu- tools 
and give the fjptimized recipes to contractors to lie used on 
Fiyi machines. 

Ac k no wle dgments 

The wot k desc^ribcd in this paper was funded by all HP sur- 
face mount centers who have Fiyi IPi machines. All fP2 
Man-Link users have helped us to undci^tand t he issues 
described in tliis paper, Don MartoreOo, Sheldon Stewart, 
Pat ManMl, and Jim Hudson have helped ut rlefining many 
issues related \o Modified Merlium nozzles and ht^ad balanc- 
ing. All membt^rs of the Man -Link leant. esi>ecially Rick Palm, 
hav^e contributed lo the implementation of tiiis project. Man- 
Link is one of t he products provided by the tlesign automa- 
tion group of (IPs [iroduct generation information systen^s 
department antl managed hy Eiko Joluisoiu 
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Reducing Setup Time for Printed 
Circuit Assembly 



In 1994, HP's Man-Link recipe-generation system was enhanced to reduce 
the time required for setting up pick-and-place machines. This was done 
by ordering the products to exploit the commonality of parts among them 
and by creating sequences of setups that differ as little as possible from 
one another This paper documents the issues and trade-offs and 
discusses the potential benefits. 

by Richard C. Palm, Jn 



Early in !993, we began an investigation into ways to de- 
crease the cost of setup lime for HP surface mount niaini- 
facturing centers. Our iuitia! uivestigatit>n cfjvereri a range 
of options, including: 

• C'oiunion selujis for l)f>th sities of a printed circuit assembly. 
All of the pans needed for Ijotli sides of the printed circuit 
assembly are placed in a single setup. 

• Partially fi.xed setups. Commonly used parts are assigned 
fixed locations on the machines. 

• Family setups. All of the parts required to buiJd a group of 
pru^ted circuit assemblies aic placed m a smgle setup. The 
printed circuit assemblies in the group are chosen so that all 
of the required parts will fii into one setup, 

• Feeder bank exchmige. Some machines offer the ability to 
change a large niuuber of parts in the setup quickly by 
means of renio%'aljle feeder banks. The operator can sei up 
the pails for a product in an offline feeder bank while the 
niachine is building a different product. The ojjerator then 
trades the offline feeder bank for the online feeder bank, 
ai\d can start bail dm g the new^ profhict mimediately. 

• Opiimization by schedule, described l>elow. 

We soon narrowed the investigation to two options. We 
considered these to offer a gocjd returr\ on investment and 
to be a good Ht with the architecture of HP's internal Man- 
Link sysietn, which creates recipes for pick-and-place 
machines* The two options were family setups and optimiza- 
tion by schedule. We asked our customers to estiiuate the 
benefit to their sites, using mathematical models of these 
options. Based on their biputs, w^e chose to proceed with 
optimization by schedule. This ^vas implemented in 1994. 



Setup ophmization by schedule takes advantage of the fact 
that many piinted circuit assemblies use comtnon compo- 
nents (Fig. 1). If the macbiue setup for eacli new printed 
circuit assembly is based on the setup of tlie previous printed 
cucuit assembly, parts itval are used in both don't liave to be 
moved, kuid the total number of paris tliat need to be set up 
(ciiUed "feeder changes") is reduced. For example, in Fig. 1, 
four parts each are used on three products. Since parts that 
are ef.>nunon to multii>le products are reused, the operator 
would only ttave to do six feeder changes (one each for 
parts 1 to 6) rather than the twelve that could be required if 
parts cbangetl slots between products. 

Further reduction in feeder changes can be achieved by 
changing the order in whicti printed circuit assemblies aie 
built. Printed circuit assemblies with a laige number of 
common parts should be built sequentially. 

The advantages of this approach include: 

• h works well if feeder space is limited. For example, it has 
been used effectively in a line containing only one Fuji CP 
pick-and-place machine and one Ryi IP plck-ai id -place 
machine. In contrast, partially fixed setups arul family set- 
ups require a larger amount of excess feeder capacity to be 
effective. 

• It does not require any additional equipment or stock, as is 
required to use feetler bank exeliange, 

• It works well for very small lot sizes, even single panels. 
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Fig. 1, Setup c^pUmization by 
schedule. 
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Disadvantages include: 

• It requires machine do\iTttin«e to ch||||^IS$eders. The user 
can prepare feeders for the next proifact but cannot set up 
oJnine and use feeder bank exchange or the Fuji CP split- 
bank mode. 

• It has limited effectiveness if the schedule cannot be set by 
the setup optimization ttml Estimates of the lost effective- 
ness vary from 10% to 60%, 

• Recipe geneiation must be dynamic, that is, recipes must be 
generated alter identifying thf printed circuit assemblies lo 
be built in a })anicular linie period. 

• Late schedule changes may reduce the tool's effectiveness, 
or require that it be rerun. 

SOFT 

A software Umi to (>i)tinuzc schedules by setup. caHed SOFT 
(for setup o/>^imiication ), was created by HP Laboratories 
and later adapteil to an UP propritn,'ir>' recipe generation 
system. This system generates programs, or recipes, for 
pick-and-place machines. Any references to SOFT in this 
paper refer to this system. 

Ttie SOFT tool worl^ on a list of printed circuit assemblies. 
It considers only Lliose parts assigned to a particular ma- 
chine for each printed cucuit Jisscmbly. First, the piinted 
circuit assemblies are ordered using a traveling salesman 
heuristic with the number ofconmion parts between printed 
circuit assemblies as the cost fund ion. Next, a setup is gen- 
erated for each printed circuit assembly, and tlie nmnber of 
feeder changes is calciilcifett. Finally, the schedule is per- 
turbed, and the feeder chiuiges are recalculated to detennine 
if a slightly different schedule wtnild tje an improvement. 
When no further improvements ran be fonnd, the program 
stops. The user can alK-r ilie r^rder (for exainplct if one 
printed circuit assembly Jiujst be built first). The program 
will then recalculate the settips. 

(Outputs of SOFT include setup fUes for the printed circuit 
assemblies, and an operator instruction file gi\1ng the 
o rile red list of printed cinuit assemblies and the feeder 
changt^s ri!<iuired between each pair of printed circuit 
assemblies* 

Man-Link 

MaibLink is a newer IIF-prr>prietary tool that generates 
recipes for pick-and-jilace machines, 'llie assembly process 
is modeled as aii ordereti list of steps. In each step, a 
macfnne or person installs pari.s on one side of the printed 
circuit assembly. To generate recijKvs for all of the sret>s in a 
pro(^ess, Man-Link exet tttes the following seiiuence of tasks: 

• Assign Reference Designators. Kesi>onsil)ility for the place- 
ment of each reference designator is assigned to a step in 
the process. In making assignment's, Man-Link considers 
other seiu])s. userHtipiit re?:i|)Otisiliilities, user step prefer- 
e!ic;es. the number of piiris eacli n^achin** c mi handle, bal- 
ance among steps, and other factors. Ilus task must be done 
once for tlie entire process, to ensure that each placement 
is lissilg^iwd to exactly one step. 

• Gencrah^ Spnii>s. For each step, Majt-Iink detemiines where 
the ptLTts assigned to the stet> shonld l»e h>aded on the [jick- 
and'phice machine, considering oiher settiiKS, rna<4iiru^ con- 
straitu,s, placement speed, and other factors. This task is 
normally done separately for each step. 



• Ogr^nifze Sequence, For each step, Man-link detemiines the 
order in which i>art.s should he placed, Tim task is alwaj^ 
done separately for each step. 

Fig. 2 shows these tasks. In Figs, 2. 3. and 4, each shape 
identifies a part of the problem space that is solved as a unit, 
either by a single program invocation or by a series of pro- 
gram invocatioiis sharing data hi Fig. 2* assigiuuent of refer- 
ence designators to steps is done by a single program in- 
vocation to easure that eac*h reference designator Is assigned 
to exactly one step. The other tasks are done by indi\1dual 
program in\^ocati« jns for each step because there is no need 
to share information among steps. 

These tasl^ are perfonned in two phases. The first, called 
stmfegic recipe gettemtf on. performs an initial subsequence 
of these tasks and stores its output in a database. The sec- 
ond phase, called iaetical tvelpe gfrnemlioft, perfonns the 
rest of the l<isks, producing the final recipes that are used to 
build the pritned circuit assetnbly. 

It did not seem pnicient to integrate the SOFT tool into Man- 
IJnk for a number of reasons. These ittcluded the SCJPT im- 
plement^ition language (Pasc^al) and the tlata structures for 
setups (SOrr uses files, while Man-Link uses database 
tables). We decided to create a Man- Link solution using 
SOPf ideas and algorithms. In tlie folio wir^g se<:*tions, some 
of tlie design issues are discussed. 

Build Lists 

To handle multiple prinhHl circuit assemblies in Man -Link, 
we introduced baiid /is/.s, which are lists of printed circuit 
assemblies. We modified the prograitis to generate recipes 
for all of tfie tJrinled chctiit assemblies in a build list, hi the 
process, Mim-Link must order the buiUl ILsf and create set- 
ups wiiU 1 1 1 h I i ni a i f t^ed er chartges. 

Ordering and Responsibility 

An early issue in tiie design was how to integrate i>uild list 
oniering into thc^ hst of tasks given above, Tlve SOPf imple- 
mentation has a single program that orders the list and gen- 
erates setut)s for one step (Fig. 3). For each of the other 
steps, all of the setnjjs m"e detennined tcigether but I he list 
order {letennined for the Ilret step cminot be altered. The 
advantage of this approacli is that the ordeiiiig algorithm 
has detailed knowledge of what part^ will or wilt not fit on a 
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n^^EClmie, and can therefore calculate (ai^d optimize) the 
exact number of feeder changes required. Hie disadvantages 
are thai die ordering prograiii must iriciude all of the setup 
code lor the tiirget inachine (tuid therefore be machine- 
specific), and that the ordering considers only one step. 
An order that is very good for one step in the process may 
be very bad for another. 

For the Man-Liak inip!emenlalion, we wanted l,o keep our 
code modular and to corisider all steps when ordeiliig. For 
these reasons, we decided to separate ordering and setup 
generation. 

As a separate tiisk, build Usl ordering must precede the gen- 
eration of setups, since the setups are dependent on the 
printed circuit assembly sequence. The next question is 
whether ordering should precede or follow the a'ssignment 
of reference designators. If ordering is done first, then 
assignment can use that information. On the other hand, 
if assigim^ent is done first, ordering can focus ac< urately on 
the parts assigned to selected machines. 

Perhaps the most compelling consideration was that our 
users wanted to be able to aJler the order after the ordering 
j>rogram had ruiij buj [jefore the setups had been generated. 
To do this within the Man-Link architecture, we haci only 
two options: 

• Make ordering the last f^ask in strategic recipe generaticjn. 
This means that setup generation must be tactical, anrl 
therefore, tactical recipe generarion w^ould always have to 
be run for the entire build Ust. 

• Make ordering a separate phase preceding strategic recipe 
generation. Tlie strategic phase could then include setup 
generatioUj and the tactical phase could be run for a single 
printed circuit assembly on a single step. 
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iriodel. 



After discussing tliese issues with our iLsers^ we decided to 
implement the second alternative. Fig. 4 shows that ordering 
is done for all products, independent of steps, before any 
other task. Assignment of reference designators to steps is 
then done by a series of program invocations sharing data 
and using ordering information. 

Equipment Sets 

Since build lisl ordering precedes reference designator 
Eissignnieni in MaivLink, the ordering cannot consider the 
set of parts assigned to a part iculai' step. We tlierefore 
tluiught we could just order printed circuit assemblies based 
on all of the partes on the printetl circuit assemblies. The 
problem with this approach is that the parts on tJne two 
sides of a printed circuit a?ksembly are often quite different. 
This could lead to poor' results for processes (^nisi sting of 
one set of machines for top-side placement and a second set 
of machines for bottom-side placement. For this reason, we 
decided to order top-side parts separately from bottom-side 
parts. To do this requires the concept of an equlpmenl set^ 
which is defined as the set of machmes used to place idl of 
the parts on one side of a printed circuit assembly For ex- 
ample, in Fig. 5, machines 1 antl 2 form one etiuipment set, 
and 3 and 4 fonu a second etiuipment seh The ordering pro- 
gram will consider separately the parts assigned to each of 
the iw() equipment set.s. 

Scheclule Dependence 

In the SOFT implementation, any change in schedide nor- 
mally requires that the SOFT program be rermi, Wc hoped to 
alle\iate this in Man-Link by separating setup generation 
from operator instruction generation, Tlie idea is to keep 
track of the parts loaded on a machine. WHion the operator 
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selects the next printed circuit assembly to be nm. Man-link 
runs a machine dependent program that comp^ires the cur- 
rent setup with the setup for the new printed f 'ircuit iissembly 
(?lj?. 0). This program lists the niinininni numi>er of changes 
required to get the required piUls for the new pmted circuit 
assembly m ihe right ylots. If tlie operator follows the deter- 
nune<1 iic hedule. changes ai^e minimized. If the operator 
deviates from the schedule, there may be more changes, but 
the setnps do not have to be regenerated. Tliis should be 
particularly effective if the on]y change is to insert a proto- 
type into the schedule. 

The difficulty with this approach is that Man-Link must al- 
ways know rhe current setup. We have a means in Man-Link 
to ensure this, Intt it is not robust and has been a source of 
frustration to our users. 

Steps and Maeliines 

A Man-Link process is matle up of a setiuence of steps, each 
of which refers to a Diatliinc A p^iriidihir machine may be 
used for mort^ tli-m on,^ step in a process, hi this case, Man- 
Link cotild (l(j one ot iw<j things, F^e^t. Man-link could treat 
each step 3iidep(*n(h'Ml}y, creating a separate sequence of 
setups for e;H h sfeji llus ussumes that the user runs all 
printed circuit iisseinbjies through a given step before gouig 
on to the next step, which is not realistic. Alternatively 
Man-Link ct:(ii)d generate all setups for a given t>rinted cir- 
cuit assembly liefore gomg on to the next printed circuit 




Fig* 5* An equipment set is tJie set 
of niachiiies used to place aH of 
the parts on one side of a printed 
circmt assembij'- 



assembly, and create a sequence of setups for each machine. 
We chose to implement the second approach. 

One residi of this decision is that the setups for each printed 
circuit assembly n^ust be sequential in the setup hst. For 
extunple^ in a two-sided surface momit process, the seuip 
for each prinied circuii a-ssembly s bottom side w^ill inmiedi- 
ately precede tlie setup for its top side, assuming the same 
machine is used for both sides. (See the next section for a 
way around tliis constraint,) 

This b a change from the SOFT implementation, which treats 
different sides of a printed circuit assembly as separate 
printed circ-uit assembhes. This turns out to be both good 
and bad — good because the sides can be ordered with oilier 
I printed circuit assembhes to reriuiiT fewer feefler €:hanges. 
but bad because J^OPT may put the sides in tlie wrong order^ 
reqnirmg manual shuBQing of the schediUe* 

One related noti^ — ^MaivLink ciui be configured to create a 
single setup for a pair of stejis usuig the same machhte. For 
exaniple, if a two-sided process uses the same CP3 machine 
to place both the top and the bottom sides of a printed cir- 
cuit assemi)ly then the user can configure Man-Link to 
create one CR3 setu|> containing all the parts required for 
both sides, hi this case, the seciuence of s(^tu|)S for the CF3 
woulfl luive only one setup for the two-sided ininted circuit 
assembly 
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Separating Sides 

Ftir certain applications, ii may hv advanlageoiis to treat the 
different skies of a printeii t irciiit assembly 3S sepaiate 
printed circuit assemblies. This wouki allow the top aiid 
bottom sides of the printed circuit assembly to be separated 
in the build list^ or evL*n to be m chlferent build lists. This 
feature would be useful for processes that use different ma- 
chines to place the top and bottom sides. 

Maji-Iink does not support this capability directly, but does 
provide a way to achieve It. The user must define a dummy 
machine that does not cause setups or recipes to be geuer- 
ateci. To satisfy the referei\ce designator assigmuent module, 
steps iLsing tliis macliine can take respoTLsihilhy for p;iils. 
The user must tlien define a top-side process wiUi a dunmiy 
step for the bottom side, and a bottom-side process with a 
dummy step for the top side. To generate recipes for a 
double-sided piinted circuit assembly, \he nser must run 
recipe generation nsing botii processes. Tlie two printiHl 
circuit assembly /process pairs can be included at tUfferent 
points in a build list, or even in chfferent build lists. 

Starting Setups 

To get the most out of o]irimization by schedule, it is best to 
take advantage of any ])aits left on the machines from pre- 
vious l:>ujlds. In other words, the last setup.s for yesterday's 
t>uild list should be an input for recipe generation for I oday s 
build List (Fig. 7), In generadng the setups for foday s first 
printed circuit assembly, we can use any parts left over fi-om 
yesterday's last printed circuit assembly setups. 

Man-Link provides this cai)ahility by saving the h^t setup 
generated for each machine. This works well as long as set- 
ups me generated by only one person at a time. If two 
people try^ to generate setups for" the same machines at the 
same time, they wiO overwrite each other's stalling setups^ 
causing all manner of confusion. Man-Link therefore has the 
constrauit tliat strategic recipe generation for build lists may 
not be done for the same machines by more than one user 
simul tan eously. 

A suggested way aioimd Oils constiaint is to have a directory 
for starting setups for each user Tliis would keep multiple 
users fiom interfering with each other, l>ut does not address 
the problem of deteniiining tlie correct starting setup for 
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each machine, thai is, how each machine will be set up 
before the first printed circuit assembly in the build list is 
started. 

Estimating Beiierits 

To assist users m projecting the benefits of optLmization by 

schedule, we constructed this model of the setup process: 

• Let N = the number of printed circuit assembhes to be built 
in a schedule. 

• Let C — the average number of parts in the printed circuit 
assemblies. 

• Let P = the pn>bability that any given part iLsed by a partic- 
ular pruited circuit assembly is also used by a second given 
printed circuit assembly. In other w^ords, P is the average 
fraction of parts shared by any two piinted circuit assemblies 
in the schedule. For typiciil build lists, this varies from 
aroimd 0. 13 to 0.37, with an average of about 0.25. 

• Let F = the number of parts the machines can hold. For a 
rP3, this is around 112, assuming that tluree times us many 
one -slot parts aie used as two-slot parts. 

• Let 1 1 = the total number of unique paits for all of the 
printed circuit assemblies m the schedule. 

• Let X = tlie total number of feeder changes required by the 
setups. 

The average number of parts that are common to two printed 
circuit assemblies is CP The total number of pans in two 
printed circuit assemblies is therefore C -\- (C - C'P), or 
2C — CR Assuming that commonality is uniformly distrib- 
uted, the average number of parts common to tluee printed 
circuit assenihlies is CP*^, so the total number of pails in 
t hree primed circuit assemblies is C -i-(C — CP) + 
(C — 2CP -H CP*^), Contuuiuig this reasoning, we arrive at 
the following estimator of 1 1; 



u = |(i-a-p)-^). 



m 



This should muuediately raise some alarms, because it pre- 
dicts tiiat the total number of mnque parts converges to C/P 
as the nmnber of printed cncuit asseml>hes (N) gets ku'ge. in 
fact, tiiis tiuns out to be a reiisonable first-order estimator if 
the number of printed circuit tissembUes is not too big. If N 
is between 2 and 5, it is pretty good, but as N approaches 10, 
it is consistently low. Fig, 8 shows estimator values and 
actual values based on a random collection of products from 
one suiface moimt center- 

Tlie number of feeder changes required, X, depends on F If 
F < C, the parts for a printed circuit assembly will not fit t>n 
the machines, so C must be a lower bound for F If F ^ I.J, 
all of the parts may be mounted at once, so the number of 
changes depends ou the conunonidity with die starting set- 
ups. If the starting setups do not contain any parts in the 
printed cirt uit assembhes, then X = U. K tJie starting setu])s 
have all oT I lie parts, X = 0. In the real world, X is generally 
between these two extremes, and in fad, C turns out to be 
a reasonable estimator. In an analysis of 25 btiild lists used 
at surface mount centers, LI predicted a 61% decrease in 
feeder changes, €ompa2ed to m\ actual decrease of 66%, 

Ordering the bidld list for maximum commonality can raise 
the effective value of P from an average of 0.26 to an aver- 
age of 0.28 in tfie 25 build lists mentioned above. 



Fig. 7, Usmg starting setups. 
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Fig. 8* Acoumcy of the L' esiimaiur based on data froni one 

surface nn)imt center. 



conv^-ing the panels and reading marks more than cmce. 
This cost can be mcKleled as follows: 

• Let V be the oveiliead per panel. This is the sum of the con- 
veying time, the time to read fiducials, and the tinie to read 
iiitage-reject marks. 

• Let S be the average number of seconds required to place a 
single eomiJonent. For the CP2 and CF3 machines, a figure 
of 0.3 second works weil 

• Let M be the lumtber of placements to be clone by the CF 
machines. 

For one CP machine, the dme required to Imild a panel is 
V + MS seconds. If two CPs m series buihl the panel, each 
pJai'ing half of the parts, the total time is: 

Total machine tinie = 2 x fv + ^ x s) = 2V 4- MS. (2) 

The Increase in cycle time caused by liavlng two macliines 
in series rather tiian in parallel is: 



Setup vs. Cycle Time 

Most strategies that reduce setup time do so at the expense 
of cycle time. In other words, you can save time setting up 
the machine if you are wdlling to li\e with setups that do not 
build printed circiut assemblies as quickly. There are several 
reasons why this occurs: 

• A setup that can be used for multiple printed circuit assem- 
blies is less compact. It reqiiiies greater macliine movement 
(either of the part feeder caniage or of the placement heads) 
to access the [larts for each printed circuit assembly, 

• On the Fuji ( 'F machines, a movement of one slot on the 
part feeder cai'riage betw^een placenumts tloes not slow the 
mac*hine down. Tlie Man-Link sequence generators take 
adviuUage of this by optimizing phwenient sequences for 
pairs of iuljaci-nl parts, t 'rueful selection (jf parts to put 
together in the setup can therefore have a big impact on the 
cycle time. 

• The Fi^ii CF3 must place all ^tall" parts after all **shorr" pails. 
An optimized setup mil have all of the tall tiaits at one end 
of the pad feeder carriage, so each printed circuit iissf^iuhly 
can be built witb a single (>ass tlu'ough the carriage. 

• Fuji IP2 ot>timization is eomproniised. Wlien Man -Link gen- 
erates a setup for a single printed circuit assembly^ it will 
balance the loads on the tw^o heads. The user can request 
that a hjgb-iise j>ai1 he loaded on both banks to further ini- 
provc the l>alau<^e. Also, liigh-use parts arc assigned to slots 
with the lowest access tunes. 

The combined impact of these effects has been measmed to 
be an incrciise of cycle time of between 5% and ICFMk For 
small lot sizes, this tsagood trade-off but rr>r large lot sizes 
(greater than 100 panels) overall throughput will suffer 

Panillel versus Serial Lines 

As nutcd ab(>\'e. tlie beiu^fit derivable trorn this setup strategy 
is di'i>endent an the amount < if excess feeder capacity avail- 
able. TJie intmediate temptation is to jjut inachuies in series 
to increase the effective feeder capaeiiy. This could be a 
mista ke , he i w e ve r, becaus e t ! i e utilization n f 1 1 lac h i nes in 
series decreases as a result of tlu^ int reased overhead of 



Change in total machine time = 



2V + MS 
V + MS ■ 



(3) 



Assume that the overhead is 17 seconds. This is enough time 
for conveying the panel and reading fotir panel fiducials and 
tWT) image-reject marks. For panels witii 1 00 j^lacements. the 
cycle linte is increased by 8ti% by the seiial configuiation. 
AgaiiiT for sonve shops tliis will be a reasonable trade-off. 

The Bottom Line 

To estimate the potential value of this optintization method, 
the user nuist: 

1. Estimate ttie reduction in setup time. If the surface mount 
center is t^tuTently perfontiing a eotnplete te;ij'dnmi *md set- 
up for each printed circuit assembly, the number of feeder 
changes should be reduced from N x C to approxiniately 

frotn equation L If it takt^s T seconds to change one 
feeder, t^he savings is (NC - i; )T. 

For example, for five products, witlt ;in average of 50 parts 
per product, and part conunonality of <)J0, the expected 
number c)f feeder t^hangc^s \' will be U^H. TTiis means ibat 
the reduction in feeder clianges will be 250 - 1(18 = S2. If 
each feeder change takes one niimite^ the total reduction in 
feeder changes will be 82 minutes, or about U^ miniUes per 
product. 

2. Estimate the iitcrease in cyde time. This will be about 10% 
of the total njn time. If machines that are cnuTcnlly nuirhng 
in parallel need to be put in series lo get sufficient feeder 
space, the ttser should also estimate the resulting increase In 
total machine time, using equation 3 above. 

In the above example, if t lie average number of placements 
per product is lt)U, and the average placement time is 0.3 
second. 1 be increase iti cycle tinte will be about 100 x 0.3 
second xUM = 12 seconds = 0.2 minut(^/i>ancL 

3. The break-even lot size can then be calculated by setting 
the decrease in setup time vi\u}\\ to the increase in cycle 
time. In the above example; 



it) miuules/producE 
0.2 minute/panel 



= 80 panels/product. 
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4, Aitenialively, the user can calrulaie the time savings per 
lot. Ill I lie ahove example, assuming 10 panels per lot: 

• Witlujut optimization: 50 mijiutesselup + 20 minutes binld 
= 70 minutes 

• With optiini/^ition; :>4 minutes setup + 22 muujtes build = 
56 minutes 

• Savings per lot = 14 minutes. 

Tills represents a 20% decrease in the time to build a lot 

We expect an improvement for lines that jire dominated by 
setup time, such as lines for prototypes or iugh-mix, low- 
volume products. If the loi sVm- is consisrenily less thmi 
100 panels, optimization by st^hedule may be a good fit. 

Coneliijiion 

Life is a series of trade-offs. We hetieve that tht* choices we 
made \\\ this work will [ufivide the best benefit to our cus- 
tomers. Weliave received enttjuragini? statistics from the 



sm^ee m^mit centers that are using the product The 
estimation methods given above should aUow other siulace 
mount centers to evaluate this strategy^ for tlieir shops. 
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Low-Temperature Solders 

The application of low-temperature solders in surface mount assembly 
processes for products that do not experience harsh temperature 
environments is technically feasible. One single alloy may not be 
appropriate as a universal solution. 

by Zeqnn Mei, Helen A. Holder, and Hubert A* Vander Plas 



Low-temperature soldering has been a subjed: of research at 
HP's Electronic Msenibly De^'elopment Center (EADC). 
Several benefits may come from developing this technology', 
including thermal shock reduction^ step soldering capability, 
and possibly, iead (Pb) eiimination. 

Thermal Shock Reduction. Tlie risk of thermally induced dan> 
ages win be reduced if the peak exposure temperature is 



reduced. A significant decrease in the peak reflow tempera- 
ture (the oven temperature at which the solder melts and 
makes the connections between the components and the 
board) will reduce damage to components. Currendy, peak 
reflow temperalures are aroimd 210"C to 230^C. These tem- 
peratures are sufficient to cause phenomena such as pop- 
comiim^ a fatriy well-known phenomenon in which air and 
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moistuie that liave been trapped in the plastic package* of an 
Tf' lire heated to (he {)om\ where tliey exiiaiul trnt] rause the 
component case to unuk open^ The damage from popconung 
is inmiediate and usually detectabie, l:)ut there are other ther- 
mally induced damages that can cause long-term problems, 
such as war^;)ing of prmted circuit f >oards or damage to ICs, 
which would also be reduced with lower peak temperatures, 

Step Soldering. The availahility of solders mih lower melting 
IKjints will make multiple reflow processes on a single boaid 
possible. For exiimple, all of the noniial component's that 
can tolerate higher reflow^ temperatures could be soldered 
10 a board using the st^uidiud p roc ess ^ and then tiie lower- 
temperature components could be abided in ai\ other reflow^ 
process. Since step solderuig is a biilk relh>w process, it 
lakes less time and is more uniform tlian hand soldering, 
and doesn't take any cUfferent equipment or special trauung. 

Possible Pb Elimination. Many low-tempei-atiu-e solders con- 
tain no lead. 

Selectioii of Low Melting Alloys 

We call a solder alloy low nwliing if it melts at temperatures 
below 183''C aiul above bO^C. Most of the alloys that meet 
this rei[uiremeiit are made of four elements: Sn (tin), Pb 
(lead), Bi (bismuth), and hi (indium). The Cd (cadmiimi) 
bearing tiiloys are not considered because of their extreme 
toxicity. Various compositions of these elements produce 
alloys that melt at miy given temperature between 50'^C and 
IS^^^'C. Conmiercially available low-melting alloys are listed 
in Table L The numbers associated with eaclt alloy m Table I 
are the percentages by weight of the components that make 
up the alloy. 

lb better understand the correlation between the aUoy com- 
positions and I heir melting temperatures^ we can use the 
ternary diagram of melting temperature* A ternary diagi"ain 
uses a triangle to represent chemical compositions of a 
three-element alloy system. A physical propeity, such as 
melting tempcratme, is plotted over the triangle. Figs, la to 
Id show The melting pouits of tern^iiy systems of all possible 
combmations of the elements BiPbSn, BiliiSn, InPbSn, and 
BilnPb. 

These diagran^ show^ what are called the liquid as tempera- 
tiwes, as opposed to the solidus temperatures. A ty^^ical 
alloy melts not at a single temj>eratnre but over a tempera- 
ture range. The sohdus temi^eralure is the highest tempera- 
ture at which an aOoy remains solid, wliile die hquidus tem- 
perature is the low^esl. temperature at which an alloy 
remains hqiiid. At the temperatures betw^een tlie solidus and 
liquidus temperaluies, an alloy is a mixtiu:e of sohd and liq- 
uid. Hie solitkis temperatures of diese ahoy systems are not 
shown iii Fig. 1. How'ever, for a few specific compositions 
labeled "e" or **E" in Fig. 1, the so-called eutectic ahoys, tlie 
solidiLs and liquidus temperatures are equal. Moys with 
eutectic com posit ions or small differences between their 
hquidus and st>lidus temperatures ai-e often fa\'ored for sol- 
deiin^ ai>p I i cations hecaiLse they melt and sohdify rapidly 
instead of over a range of temperatures. 

Not aU the compositions fotmd on the ternary^ phase dia- 
gram are suitable for soldering applications. To determine 
wliich are most appropriate, we use tlie following criteria: 
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• Wettability. A metal is said to have wetted mtJt a surf ace 

if it fomis a sound metallurgical bonding with the surface, 
VVletting is essential in the soldering process because it 
ensures that the joint created won't come apart at the inter- 
face. Any new alloy must be able to m et to the common pad 
surface finishes: Cu, PbSn. and Ni coated with Pd or Au. 

• Reliabilit>'. Lower-temperature allo>^ should still be reliable, 
so we measiue the follo^^lng properties to estimate how 
reliable solder joints made of an alloy vsiil be: shear 
strength, creep resistance, isothermal fatigue resistanccj 
and thermal fatigue resistance. 

• Long-term stability. Microstnictural evolution^ grain growth, 
and recrystallization contribute to changes in tJie solder 
joint mechanical properties o\'er time, so we want to make 
sure that the changes are slow and stable anti \\on't reduce 
the mechanical properties of the solder joints to mmccept- 
able levels over the life of the joint. 

• Practicality Alloys used for niass production should be 
cheap and widely available. It should be possible to make 
them into solder pastes so that they can be used in standard 
assembly processes, and suitable fluxes should be avmlable. 
The alloys shouldii't be more toxic than what's ciuxently 
used. 

To begin otir alloy selection and evaluation, we found refer- 
ences in the available literature to low-temperatui^e alloys 
that might fit these requirements. Three alloys were selected 
for further evaluation: 

• 43Sn4:3Ph 14Bi. The solidus temperature of this alloy is 144''C 
and the liquidus temperature is i63°C. 20''C lower than 
63Sn37Pb, but with similar mechanical properties. 

• 58Bi42Sn. This composition is a eutectic alloy rhat melts at 
139"'C. l! is lead-free and strong, but brittle. Also, its fatigue 
resistance is quest ioiu^ble.^'- 

» 40Sn401n2()Pb. The solidus Lerni^erature of this alloy is 
12rC aiid the liguitlus teinperature is 130^'(.". Ix is soft and 
ductile* It doesn'l have the problem of embrittlement wheJi 
soldering to thU^k gold surfaces, like PbSn, because of the 
higii In content. Hnfortunately. the higti hi content drives 
the price of this alloy up because In is extremely expensive 
right now. 




Fig. 2* Solder bead formed by reSowing paste on a plain Cu surface, 
a is the wettit^ angle. 

These three were chosen mostly because dtere was more 
information available on them than on other low tempera- 
ture alloj-s, not necessarily because \^'e ihouglU Uiey would 
make the best solders. They provided a starting point 

Because the technicaJ data on the low temperatiue alloys 
was hniited and inconclusive,'^ we conducted a series of 
tests based on our selection criteria listed above, 

Wettiiig and Solderability 

Two types of tests were conducted to look at the wetting 
performance of these alloys: spreading tests anti wettiag 
balance tests. 

hi spread tests, a doilop of solder paste is deposited on a 
copper board or test coupon. The coupons are then heated 
to SO^C above the liquidus temperature of the alloy in an 
oven under a nitrogen atmosphere. Tlie dollop of solder 
paste melts, and as long as tiie flux is active enough to re- 
move the siuface metaJ oxides, the solder forms a bead, or 
cap (see Fig. 2). The diameter and height of the solder cap 
can then be measured to detenuine tlie c;ontart ai^gle (a) of 
the solder to the boarrl Tliis contact angle, or wetting angle, 
is a measure of how well the solder wUl wet in a surface 
mount process — smaller is better. 

Factors that affect the si>read test include the activity of tlte 
tlux, the surface tension of the molten alloy and the iilloy^s 
ability to make a n^etallurgical liond wifh the surface metiil- 
lization. All of these factors liave lo Ijc taken into account 
when interpreting the results of spread tests. 
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Fig. 3. Welting angles deiermirted 
[rmn spreadiiig tests of solder 
paj>tes on copper. reQowed in a 
rittrDgeii oven. The x axis indicates 
the solder alloy <* ajid refjcnv temper- 
ytiin^^. The fiiixs^s are inclieated at 
tlie lops of the bars (V^/C = water- 
cleat i, NC = no -clean J It MA = rosin 
niild]jr*aeiivatBd). 
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The results of the wetting angle tests are shown in Fig* S. 
The 63Sn;37Pb and 4aSn43Phl4Bi aDoys both wetted well 
and similarly with the same flux. The 58Bi42Sn and 
40Sn40In20Pb alloys generally wetted the copper sitrface 
(a < 90°), but not as well as the other two alloys, averaging 
two to three times the wetting tmgle with the same fluxes. In 
fact, the 40Sn40In20Pb alloy dicht'i wet at all \^1th one no- 
Clean flux (NC2j. Tliese differences may have to do wnh the 
fact that indium and bismuth oxides are more difficult to 
remove than tin and lead oxitles. These alloys also have low- 
er surface tensions than Fb Sn. 

Another factor in how the lower-temperature alloys per- 
formed is tliat the current water clean and no-clean fluxes 
w^ere developed for 638n37Pb and activate at about ISO'^C. 
They may not be suitable for the low-temperature solders 
since most of the low^-tcmperatiu:e solders melt at tempera- 
tures below 150'^C. Wetting balance tests were conducted to 
find fluxes that w^ould be appropriate for use at lower tem- 
peratmes, and the results of those tests are presented in 
reference 4 and in the paper on page 99, 

EeMability and Long-Term Stability 

Before we could suggest that anyone change from PbSn 
solder to an alternative alloy, we needed to imderstand the 
mechanical properties of the alloy w^ell enough to know 
what the trade-offs would be. Therefore, the bulk of the 
tests we did to evaluate the alloys focused on the areas of 
shear, creep, isothermal fatigue ^ and thennal fatigue. 

Shear. Solder joints experience shear because of coefficient 
of thermal expansion mismatches. To look at the beha\dor of 
solder joints of cLifferent alloys in shear, we used specimens 
as shown in Fig. 4. These specimens have nine solder joints 
of dimensions 0.050 by 0,080 by 0.010 inch sandwiched be- 
tween two copper plates. When the ends are pulled in a test- 
ing tnachine at different temperatures and strain rates, the 
stress in the solder joints can be measured. Plotting the 
nreasured niaxinnmi stress agaijisi the stram rates gives us 
the relative shear' strength of the different alloys and allows 
us to compare rhem to PbSn. 

Our shear tests were conducted at three temperatures 
(25°C, G5^a and 1 1 OX) and at three strain rates (lO"-, 10 '^ 
and 10^ per second). The results of the shear strength tests 
for the low-temperatuie solders and several high-temperattu'e 
solders are plotted in Fig. 5. 

FVom these plots we can see that at 25''C, imder the same 
strain rates, 58Bi42Sn is the second strongest, inferior only 
to a high-temperature Pb-free alloy 43Sn43Pbl4Bi had about 
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Fig. 4. Specimen for shear and €reep tests. 



Fig. &* Results of shear strei\gth test5 for the low- temperature 
solders and several high-teiriperature solders at (a) room 
temperature, (b) 65^C, and (_c) llO^a 

the same strength as 63Sn37Pb, while 40Sn40In20Pb is the 
softest. As the temperature increased to 1 lO'C, the low- 
temperature solders became much softer while the liigh- 
teniperature solders were stili relatively strong. 

Creep. If a constant load is applied to a material while it is 
held at an elevated temperature, it will deform, or floW', over 
time. This time dependent defoiTuation is called creep, and 
is most significant at absolute temperatiues greater than 
about half the melting point of the material. Since creep is 
the maiji deformation mechanism in solders, it's important 
to know how creep resistant a new^ solder alloy will be. 

The same kind of specimens used in shear tests were used in 
the creep tests. The steady-state strain rates as a function of 
shear stress at 2d^"C. 65'=C. and POT are plotted in Fig. 6. lite 
data has been fitted with standard creep (Dom) equations: 
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Fig. 6. Steady-state creep (stmlrt) mtes at SC'C, WQ, aiid 90*€ as a ainction of shear stress for 63Sn37Pb (a) and the low temperature 
solders; (b) 5eBi42Sn, (c) 40Sn40In20Pb, and (d) 43Sn43Pbl4Bi, 



where y is the shear strain or creep, A is a niateriats constant, 
T is the shear stress, n is an empirical constant typically be- 
tween 3 and 7, II is the activation energ>; R is the gas con- 
stant , and T is the ahsolute temperature in K. The resulting 
Doni equation parameters are listed in Table II. 

Table II 
Creep Equation Paramater^ for Three Sotder Alloys 

M 
Altov A 

40Sn40In20Pb 4.0488 x lO"* 

58Bi42Sn 5.5403 x 10"' 

43Sn43PbI4Bi 0.11552 

The rupture strains of the low-temperaturc* solders were 
also determined from the creep tests. 58Bi42Sn showed the 
slowest creep rate but the least ntpi uie strain fur the same 
stress compared with the other low-temper atiu-e solders and 
the G3Sn37Pb, while 40In4QSn20Pb exhibited the fastest 
creep rate but the largest rupture strain. 

Isothannal Fatigue. WTien maierials art* subjected to small 
repeatefi U>ading, they can eventually fractun\ Tliis process 
of gradual fracture is called fatigue. Solder joints experience 



n 


(kcal/mo 


2.98 


22.00 


4,05 


16.85 


2,94 


17.05 



loading because of coefficient of thermal expansion mis- 
n\atches. These loads are cyclic, caused by temperature 
excursions during operation. IsothemiaJ strain cycles can be 
used to rapidly sitnulate joint exposure to show relative fa- 
ligue lives of different solder Jiiloys, There is a relationship 
called the Coffin-Manson Law, which is one way of estimating 
the fatigue life of the material P^atigue life is defined as the 
number of i:ycies at a given strain that will cause faihu"e in 
tite material, 

Coffin-Manson relations for the low-ieinperature solders 
have been determined at both 25''C' ajid 75''C. The data for 
58Bi42Sn and 63Sn37Ph is slicmTi in Fig. 7. The isothermal 
fatigue life of 5HBi42Sn is shorter than 63Sn37Pb under the 
same cyclic strains. 

Thermal Fatigue. Although isothermal fatigue can be used to 
estimate fatigite life* we also do acttial tbemtal fueling to 
show how t he Jc Jints will perform as the temperature cycl(?s. 
For our thern^al fatigue tests, a new type of test vehicle wiis 
designed (see Pig. 8 J. F^ve ceramic plates, all 1/16 inch thick, 
and 4, 2, I, 1/2, iuid 1/4 inch square re.spectively, were sol- 
dered onto a I/8-inch-thick FR4 board. Eight solder joints 
0.010 inch thick and 0-050 inch hi diameter, Ifjcated in a ring, 
were sanchviched between each ceramic plate and the FRA 
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Fig, 7, Istjlherm^il shear fatigue lesl results. 

board. Each solder joint was indKidually tested for electri- 
cal c onrinviity while being teniperaiure cycled in a thermal 
ham her. TV'o teinperature profiles were used, 25' C to ys^'C 
and -20''ClullO%\ 

Tlie results of tlie - 20V-to-lin°C test are plotted in Fig. 9. 
Since the test is stilJ in progress, only ttie fatigue flata for I fie 
failed solder joints is plotted. 63Sn37Pb lasted longer Ihaji 
58Bi42Sn, and approximately the saine number of cycles as 
43Sn43Pbl4Bi. The 4USn401n20Pb solder joints have tlie 
longest fatigue lives. 

Practicality 

To examine the practical side of using these alloys^ we did a 
prototype build. Since the 40Sn401n20rh alloy is so expen- 
sive^ it's an unlikely candidate for large-scale pioduction, so 
we excluded it from the prototy|)e builds. The 58Bi42Sn 
alloy is hturder to solder than 43Sn43Pb 14Bi (it has a lower 
melting temperature and its oxide is harder to remove), so 
we cho.se to test tlie worse case of the tw^o remahiing alloys 
and build with 58Bi42Sn. 

The 58Bi42Sn alloy w^as made into a solder paste with a 
water-soluble RMA llux/' This kuid of flux was used because, 
unlike most standard no-clean fliLxes, it is active at the low^er 
oven temperatures used with BiSn. Tlie assembly we chose 
for this btiild had a variety of components, including 
0. 026-inch-pitch compon ents. 

Two tyjjes of board platings were used: organic coated cop- 
per (OCC) imi] hot air solder leveliiig (IIASL). These coatings 
protect the copper patls from oxidation before tiie reflow 
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Fig. 9. Results of the "20^C-to-lI0^C thermal fatigue test. Fatigue 
lives are sfiowu only for joints that had failed at the tii[ie of writing. 

process. For OCC, the copper paris are coated with a tliin 
layer of a polymer that presen'es the soideraliility of the 
surface by preventing the oxidation of the copper under- 
neath, but btirns off during the reflow^ process to allow^ for 
metallurgical bonding fietw^een the surface and the solder. 
HASL or HAL (hot air leveling) accomplishes the same pro- 
tection but uses a thin layer of PbSn solder that has been 
biownn level with air knives. 

The entire assembly process was the same as for 63Sn37Pb, 
except that a different reflow- profile was used. The low- 
temperature profile had a preheat period of 4 minutes at 
130°C and a peak period of 1.5 minutes at temperatures 
betw^een 138-C and 175'^C' (0 to 39 '^C above the melting point 
of the alloy), 

TUenty boards were built with no defects. The boards passed 
functional tests as well as out-of-plane random frequency 
vibration (45 minutes at 6g) and board environmental stress 
testing (BEST— ttiermal cycUng from -45^C to 100°C, 1 hr/ 
cycle, functionality monitored tlMoughout). 

Failure of 58Bi42Sii on Fb-Containing Surface 

During the thermal cycling of the jirototype boards, we 
observed a thermal fatigue failure mechanism of the BiSn 
solder on Pb-containing surfaces.^' Some components on the 
prototype boards fell off after about 500 cycles of BEST. 
Boards soldered with G3Sn37Pb failed after about 9€0 
cycles. 

Fig. 10 shows top views of the 58Bi42Sn solder joints before 
and after BEST Before BEST, the solder joint surfaces were 
smootii. After BEST, die solder joints between OCC bo£U"ds 
and the components \\ith .\i-Pd coating remained smooth, 
but the solder joints betw^een eitirer the HAL t>oards or Uie 
components with PbSn coating developed vei-y rough sur- 
faces. This roughness corresponded to the extraordinary 
giain growth as showTi in the cross-sectional views of solder 
joinlsin Fig. IL 

Tlie reason for the acceleiated grain growth and phase 
agglomeration was that the Pb from component leads arid 
llAL coatings on the pads had dissolved uilo the BiSn joints 
during the reflow process and formed 52Bi32Pbl6Sn, the 
ternary eutectic phtLse of the BiPbSn system (point E m 
Fig. la), which melts at 95 ""C. Since each cycle of the te.st 
took the temperature to lOC'C, that phase became liquid at 
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Fig. 10. BiSn joinls (a) between a Ni-?d component lead and an organic c:oated copper board before thennal i:;yt ling from -45°C to lOO^C, 
f b) iieUvften a Ni-Pri (!on iijonent. lead and an nrjt?anic f^oaled tjtjpijer btiard after thermal cycUng, (c) tietwes^n a Ni-Pd componeni lead and a 
]m}\: air leveled IxjarcJ aFter thc*mial cyelingr and (d) betwe^ri a PbSn-coated component lead and an or^nlc coated copper board after tJif^r- 
mal cycling. fHeprinted from ASME Technical Paper Jj^5-WA/EEP-4. © CcjpjTight 1995 ,4KME. Reprrxlurtd wilh perTTiisston.) 



tiie grain boundaries and provided channels for fast atom 
transportation. 

Although only a tiny i>ercentage of PIj on the l)oarfis or on 
the coniponenl k'ads dissolved into the BiSn joints, the 
snifdl ajnonnl of the (emary putpctic" ruins Ihe luefhimkal 
properties over tlit^ roni"se of themial c^ycliJti^ lo 100 X\ The 
joint goes from having a Hue microstnirture (as fomied) lo 
essentially ha\dng large chunks of Su aiid Bi held together 
l>y some wc?ak BiPljSn. whitrh indicates tliat BiSn is only 
compatible with Pb-free surfaces. 

Discussion 

With aJl tht^ riata we've collected, ifs still difficult to c^onclufle 
which low- temperature alloy is the best in general. Each has 
different advantages and disadvantages- They offer a spec- 
trunt of melting ranges: 43Sn4:JPbl4Bi melts at 144^C to 
163' C, 58Bi42Sn melts at im^C, and 4(lSn4t)hY:aOP!) melts at 
12W to V'iiyC. Each has certain benellLs we might want, 
such as 40In4tJSn20Pb soklermg on Au-coaterl surface with- 
out enibiittlcn^ent, but also has iraden^ffs^ sucti as BiSn's 
hitoUiiance for Pb on the printed circuit board and rompo- 
neot leads or In s i^xUemcly higl^ cost. 



Most of the test data obtained so far is positive, witli a 
rouple of exceptions. Tliese resuhs .seem to indicate that 
loW'iemperature soldering with one or more of the alloys we 
in\ estigated (or some closely related alloys) is fetisihie us a 
mEmufactnring technology The exceptions inclucie (1) the 
nonwetling of 40In40Sn20Pb with the no-<dean fluxj and (2) 
micros! ructural coaiiiening and early failure (iuring the ther- 
mai cyclit^g of rv8Bi42Sn joints on PhH-ontiuniug surfaces. 
TIm* riml i)roblem is l>eing addressed in a llux development 
program, working with paste vendors to create fluxes 
intended for use in low-temperaliu^e ai^phcations with the 
harder-to-soider alloys such as 58Bi42Sn and 4nin4()Sn20Pb. 
The solution for the second iiroblem lias not been obtaineilt 
although several oiitions are being pursued. 

Conclusion 

Tile ajtiJlit ntion of lowMemficnilnre soiders in surface mount 
assembly proc*»sses for products tluit do not experience 
harsh temperature emironments is ijet'luucally feiisible. Low- 
t temperature assembly appears promising as an addition to 
thc^ snrface mount landscape as a way <if incrfvTsing jnocess 
flexibility and component rcvliabilily However, one single 
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Fig, 11» SEM cross section views of two solder joints (it the same 
magiiiilcation after themial cycling, (a) BiSn joint between a Ni-Pd 
component ail d an organic coated copper board, (b) BiSnjoinl 
beLiveen between a PbKivcoated component and a hot air leveled 
board. (Reprinted from ASME Technieal Paper 95-W.VEEP-4. 
© Copjiight 1995 ASME. Reproduced with permission.) 



alloy won't be a universal soltation. Specific component and 
^issemhly reqiiirement.s v^ill have to be consiciered in choos- 
ing or tailoring the best solder alloy for each application. 
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Assessment of Low-Temperature 
Fluxes 



The subject of this paper is the evaluation of the wetting baiance as a 
technique for studying the flux activity of newly developed 
low-temperature solder paste fluxes. The most effective configuration of 
the wetting balance was the standard configuration with only one change: 
the PbSn eutectic solder was replaced with a eu tactic solder alloy with a 
melting point of 58^C. Since 58^C is significantly less than the proposed 
activation temperatures of the solder fluxes, wetting curves as a function 
of temperature could be studied for each of the fluxes. The resulting data 
was used to rank the fluxes in terms of their activation requirement 

by Hubert A. Vander Plas, Rossell B. Cinque, Zequn Mei, and Helen Holder 



Solder alloys with iiieltmg temperatures between 1 10°r and 
160 "C aie rurrendy imder evaluation within Hewlett-Packard. 
An investigation of die mechanical properties of those solders 
has indicated that a suiiable alloy can be found in the ternary 
or binary' subsets of the BilnPbSn system (see article, page 
91). However, alloy selection is only the first step in devel- 
oping a low-temperature soldering process. A suitable flux 
must be chosen for use in a solder paste m\d the alloy-flux 
interaction must be studied. Thus, the ability of fluxes to 
activate at temperatures 20 to ^O^C below the melting point 
of die alloy must be evaluated* In die case wliere different 
solder metallurgies have similar mechanical properties, 
the opiiiTial metalliirgy for a low-temperature process may 
be deterniined by the availability of the appropriate flux 
chemistry. 

For the flux selection phase, there is no standard procedure 
for testing the activity of a solder flux. Tlie degree of wetting 
in a system (solder, substrate, atmosphere, lluxj may be 
characterized with a sessile spread test or by a wetting force 
measurement, (The sessUe spread test is often simply called 
a spread lest.' ) The two tests are complementary. Kacb of 
tlw tests involves a Ijala^uung of surfa^-e tensions at a three- 
pliase jiuiction. For ai^ assessment of flux activit>'. a dyiiajuic 
measurement Is more appropriate tftan a static nieasurentent 
Thus, the wetting force measurement is preferred to the 
sessile spread measurement. 

The wetting balance w^as developed to test the solderability 
of component leads in a wave solder process. Tlie technique 
has been adapted to characterize the solderabihty of surface 
moimt component leads." The focus of this paper is the eval- 
uation of the wetting balance as a technique for studying the 
flux activity of new ly developed low-temperature solder 
paste fluxes. Specifically, the Multicore MlfST System U 
wetting balance was modified to evaluate flux activity at 
lower temperatures. Sample preparation and testing prtjce- 
diires were adapted to ct>n>paie the wetting of various low- 
temperatiure solder alloy/flux conibinations. 



Review of the Wetting Balance 

A welling balance measures ihe force produced by the solder 
meniscus when a solid test specimen is partially mm^ersed 
into a molten solder The force is plotted as a function of 
time to produce a wetting curv^e. The measured force, F, m 
the sum of tw^o components: a w^etting force F^^ and an 
Ai'chimedes buoyant force F|^. 



F = Fw + Fi, 
= PYivCOse - pgV. 



CD 



where p is the sample perimeter. y\x is the liquid-vapor inter- 
facial energy, 6 is the liquid contact angle, p is the solder 
density, g is the gravitational acceleration, and V is the sub- 
merged vokune of the solid. Fig, 1 shtjws the relationship 
between the solder meniscus and the wetting curve. The 
buoyant force, shown as a dashed horizontal line in Fig. 1, 
is detenninet! by the immersed volume. Since this remains 
constant throughout the best, the evolution of the wetting 
curve reflects changes in vvetting force as the solder menis- 
cus rises. The act of immersion (Figs, la, lb) causes the 
meniscus to curve dowTiw'ard, producing a negal ive wetting 
force. As the meniscus rises (F'ig. Ic ) mid becomes horizon- 
tal, the wetiing force tends to zero. If solder wets the speci- 
men, the meniscus mil climb above the level of the liath. 
producing a positive wa^tting force. Eventually, the solder 
meniscus reaches its equilibriimi conliguration (Fig^ Id) and 
the wetting curv-e comes to an equihbrimn value. 

When using wetting force measurements to study flux 
efficat^v. it is essential lo understand how fluxes may affect 
wetting curv^es. There are essetttially only two [xunts of 
comparison for wetting curves: the ec|Uilil>riuui wetting 
force and the rate of wetting. From equatioti Ut can be 
seen tliat the wetting force is prcjiJOilionfii to die ctjsine of 
the sokler contact angle B. Tiie equilibrimn wetting f«>rce is, 
therefore, proportional l*i ihe cosine of the equilibriiun ( (in- 
tact angle %q. For simple systems, as shown in Fig. 2u, the 
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Fig. 1. Relation between tlie solder mfnisrus diirj Lhe wetting 
eur\^e. 

equilibrium contact angle is given by Young s equation:^ 



Ys^^ - Ysi = Tlvf^OsOpq 



(2) 



where yj^y is the solid-vapor inteifacial energy, y^^i is the solid- 
liquid interfacial cnerg\; and ^/iv is the hquid -vapor mtcrfacial 
energy. By corubimng equations i and 2, the equilibriimi 
wetting forc^e Fvv,e(( is deterniiiied by the difference m the 
solid-vapor and solid-liquid surface energies: 



Vsf 



nv 




(aj 



(HI 



Fig. 2* The balance of surfar-e energies at the three phase 

JDiiction. (a) Basic system. Cb) More complex system with 
flux forming a \tscou5 ring around the solid. 



Fw.c^q = PfY^^r - Vsj), 



f3) 



Thus, fluxes may improve the wetting force by increasing 
sohd- vapor surface energies or by lowering solid -liquid sur- 
face energies. Notice that tiie liquid-vapor surface energy 
does not appear in equation 3, 

The system becomes more complex when flux forms a vis- 
cous ring around the solid. As shown in Fig. 2b, flux re- 
places vapor at the original three-phase j miction, idtering 
the surface energies, which deteiTuine the wetting force. 
Finthennore, the mass of flux and the creation of two addi- 
tional three-phase junctions may alter the wetting force by 
distotUng the sJiape of the solder menisrus. Despite these 
coni]:ili cations, measurenient of the wetting force shoidd still 
provide uselul information that reflects the efficacy of the 
flux. 

Tlie second point of comparison for wetting curves is the 
rate of wetting. This can be reasonably defmed in a niunber 
of ways. In tills paper the rate of wetLmg will he taken as 
the time to reach I he buoyant force (9 = 90"). hi the stati- 
dard mode of operation, tiie heat for tlux ac'tivation is sup- 
plied when the specimen is immersed inl:o the solder bath. 
In this case, progiess of wetting may be limited by the rate 
at wliich flux reduces the surface oxide of the specimen. 
The time to wet, t, noniially follows the exponential fonii 
expected for an activated process: 

t = toe^/^T^, 

Where to is a constant, k is Bolts^rnaun's constant, T is the 
temperature of ttie solder bath, and Q is im activation euergj. 
It follows that higher temperatmes and more active fluxes 
will produce more J^apid wettmg. Tlie situation is altered 
when a furnace preheat is used for flux activation. In this 
case, oxide reduction atid the rate of wetting wiD depend on 
tiie time at liigli temperature m the furnace. If the flux 
works properly the surface oxide mU have been reduced 
before initiation of the wetting test. 

Procedure 

The activadon requirements of low-temp e rat n re lltixes and 
the effects of flux alloy interaction were inv-estigated using a 
Multicore Universal Solderabihty Tester (TVIT 1ST II J. All tests 
were conducted in air using a stiimdai'd copper wire as the 
test sjiecimen. Standaid samples consisting of 1 -mm -diameter 
copper wire were prepaied by etchmg the as-received v^ire 
to remove ail surface oxides. Tiiese samples were aged at 
lOO^T' for one hour in air to produce a imifomi, repeatabie 
oxide coating on the samples. 

Fluxes were apphed hi one of two ways. First, wtien the flux 
was in liquid form, the specimen was dipped into the liquid 
to produce an even coat. Tlie liquid fluxes (Actiec 5, Actiec 2, 
and SMA'A) are standard fluxes pro\1ded by Multicore with 
the MUST II system. Second, when the fliuc was part of the 
solder paste Oiix veliicle, a unifonn \\'eight of flux vehicle 
(approximately 4 to 5 mg) was evenly spread on the surface 
of the Cli wire. 

Since the goal Wiis to evaluate each flux as a component of a 
solder paste, all of the experimental fluxes were obtained iis 
pan of the solder paste flux vehicle, that is, tiie solder paste 
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fig. 3. Hie three configunitiojis of 
\l\e weu'mg balance studied. 
I a) Standard configiiratiDiL 
fh) Fimiiice preheat CQiiDgiiration. 
I r) Mitrobalh configuration. 



mtlioyt the sold^^r. All of the fluxes— Dii5£ L flitx 2, aiui fiiix 
S — evaluated in this program were low4emperalnre flux 
systems under tievelopnieiit. The perfoniiancp of the de\^el- 
op mental fluxes was compared to a flux vehicle dev^eloped 
for use with eutectic PbSn solder. 

The Mtilticore wetting balance was sel up In the three differ- 
ent conflgurations shown in Fig* 3. 

• Standard conflguration (Fig, :Ja), This is the noimaJ mode of 
operation for the Multicore MUST IL The copper wire is 
dipped into a large voliinte (6 cm iti diameter by 5 cm deep) 
of molten solden Two different sokier alloys were tised m 
the large bath: eutectic PbSn, which melts at 183'^C, and 
4f^Bj2nnlSPbI2Sni a quatemaiy eutectic alloy (the numbers 
are tite percentages by weigJtt of the four components of the 
alloy) that melts at 58 ^C. Heating the sample occurs when it 
is dipped into the molten solden 

• Furnace preheat conligination (Fig 3b). A separate heater is 
attached on top of the solder bath in the slattdard configtira- 
tion. This allows the sanijile to be heated before immersion 
into the molten solder. The preheat temperature can be con- 
trolled independenlly of the solder bath temperature. 

• Microbalh configuration (Fig. 3c). The volume of molten 
solder is reduced to J3 cm in chameter Ijy 0.5 cm deep. This 
con II gii rati on niininiixes the amount of each solder alloy 
tliat is required to do Uie tests. 

When the qtiateniaiy etitectic alloy is used in the standard 
configuration, the bath temperature can be set to investigate 
the activation as a function of temperature for the low-tem- 
perature fltixes. The furnace imebeat technique is a variation 
of the standard test that was developed to imitate more 



closely the thermal cycle of a statulard surface mount sol- 
dering process. The furnace, moiuued directly abo\ e the 
soider bath, provides control of the specimen temperature 
independent of the solder bath temperature. FuiaUy, the 
microbatb was used to investigate the effects of flux-alloy 
interaction for a variety of alloys. The microbatlis are alumi' 
num containers tJiat were machined to sit atop the Ml -ST II 
globtile heater. The baths, which hold less than 10 gr^ims of 
solder, mmintize the anioimt of solder required for testing. 
The microbath setup yielded more reproducible results thati 
tlie standard globule tests provided by Multicore 

Results 

Equilibriuin Wetting Force. Differences in eqtuhbriimi wetting 
force caj^ t>e [> rod need either by varying the solder bath 
composition or by varying the flux composition. Fig. 4 
shows die differences in the equilibriun^ wetting force pro- 
duced by varying the solder composition. In this test, both 
the PbSn eutectic solder and tl\e BilnPbSn quaternary eutec- 
tic solder were used witlr the slaitdard configuration aitd a 
bath temperat ure of 235^C\ One flux, Actiec 5, is plotted for 
both alloys and clearly shows tlie difference in the equilib- 
rium wetting force. 

Fig, 5 shows the differences in the equiUbriimi wetting force 
that can be produced by changing the flux composition. Flux 
I and flux 2 are two different cxtjcri mental low-ieruf^erattue 
fluxes. Tliey were lioth tiscd with the etifectir (itJalernarv 
alJoy imd a bath temperature of 1 90 <J in tlie microbath con- 
figuration. Tests conducted using flux 2 exhibit a consistently 
greater equiMbriunt weUiiig force. 
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Fig, 4. The effect of solder composRIon an the equilibriiim 
wetting force. 
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Fig. 5* The effect of flux vehicle composition on Uie equilibrium 
wetting force. 
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Fig. 6. TJne effect of fltix activity on wetting times. 

Rate of Wetting. Differences in the rate of wetting can be pro- 
duced by varying the flux composition or by varying the bath 
temperature. Fig, fj shows the difference in wetting rate as 
the hydrochloric acid content (flux composition) is varied 
from to 5% usuig the standard liquid fluxes supphed by 
Multicore, These tests used the standard coniiguration with 
PbSn eutectie solder and a bath (eniperature of 235X. They 
illustrate that the wettuig balance is capable of detecting a 
change in wettmg rate as the flux composition is changed. 

Differences in the rate of wettmg produced by vaiyang tlie 
bath temperature are shown in Fig. 7. These tests were 
conducted using the standard conflgiiration, the quaternary- 
alloy, and flux L The bath temperature was varied from 
liO^C to 160''C as indicated. Each curve represents the 
average of tw^o tests. The wetting beha\ior improves as the 
bath temperature is raised. At 160°C, tlie equilibrium wetting 
force reached its maximitnt value of 0.5 niN. 

The furnace preheat configuration provided a method of 
changing the flux activation temperature while maintaining 
a constant solder l>ath temperature. For the ciala presented 
in Fig, 8j the solder bath temperature was seT at a constant 
value of lOC'C using the quaternary eutectie sol den The 
activation temperature was changed by varyuig the power to 
the heater In each ca.se, the sample was submitted to a 
short (BQ sj preheat at the indicated power setting before 
immersion into the solder bath. Fig, 9 shows the tempera- 
ture as a function of time for each power setting. Insertion 
into the solder bath and the stait of the SO-s preheat are at 
time = 50 s in Fig. 9. As the power is increased from to 
60% ( -- 50°C to - leO^^C), the rate of wetting unproves and 
the equilibrium wetting force remains constant. The furnace 




Flux ± Flyx Z 

Solder ^ BilnPbSn Eutectie. 100^0 

Preheat Duration = 3D s 



Fig. 8. Wetting cia-ve for flux 2 as a function of furnace prelieat 
power settings. 

preheat was intended to replicate the flux activation time 
used in a nomial reflow furnace. Thus, preheat times of a 
few minutes were planned. However, longer preheat times 
produced a progressive deterioration of the wetting behav- 
ior. The low-temperature fluxes were unable to protect the 
specimens from reoxidizing during the longer preheats. Pre- 
heating in a nitrogen atmosphere was considered. However, 
this option requires a msO or modification of the equipment 
that was outside the scope of this project. As a result, the 
objective of using the preheat configuration to assess flux 
activation requirements was not accomplished. 

Analysis 

Equilibriuin Wetting Force. Figs. 4 and 5 indicate that the wet- 
ting force measurement is able to distinguish the effects of 
varying the solder alloy and the flux composition on the 
equihbrium wetting force. From equation 3, the wetting 
force is reduced by the difference (y^v - YsO- ^^^ tlie test 
sho^Ti in Fig. 4, the solid, vapor, and flux are constant. As a 
result, y^^ should remain constant tmd the differences in the 
equilibritun wettuig force are produced by variations ui "/^. 
In Fig. 5, the solid, hquid, and vapor remain constant and the 
flux is varied. The equihbrium wetting forces produced by 
flux 2 are consistenfly greater thaiT those produced by flux 1. 
This difference is difficult to associate with either y^^v or Ysj. 
The equilibrium wetting force is a function of both the solid- 
liquid and the solid-vapor interface. Both of these interfaces 
may depend on the presence of the flux. The solid-vapor 
interface will be influenced by the presence of the flux. In 
addition, different fluxes will remove surface oxides from the 
solid with different etTiciencies. Thus, the obser\^ed differ- 
ences in equihbrium wetting forces are difflcult to associate 
with either interface. 




SDltfer = BJInPbSn Eirtectic 



Fig. 7- Wetting cun^es for flux Ismd funcLion of solder temperature 
using the quaternary aOoy as the colder bath. 
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Fig. 9, Temperature calibration curves for the preheat furnace. 
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Fig, 10, Wetting curves compariitg tlie wetting behavior of flux vehicles. The BilnPbSn euiectic solder ^'a& used for each test. The label for 
each curve is the solder bath temperature. 



Rate of Wettiitg. Fig$. 6 and 7 indicate that the rate of wetting , 
defined here as inversely proportional to the time to cross 
the F^r - axis, is a function of both the flux composition 
and the activation temperature. In Fig. 6, the solid, Viqmd, 
and vapor remain constant and the flux is variable. The rate 
of wetting incre^ises as the acid content of tiie finx increases. 
The rate of wetting is dependent on the degree of oxide 
removal, which is a function of acid concentration and 
temperature. In Fig. 7, only the temperature was varied. 
The rate of wetting increases with increasuig temperature 
and the equilibrium wetting force reaches its maximum at 
160*^0, This indicates that the flux has effectively removed 
surface oxides within the first three to fotir seconds at this 
temperature. 

Ranking of Low-Temperature Fluxes 

The four plots in Fig. 10 compare the wettiiig behavior of the 
three developmental fluxes — flioc 1, flux 2, and fltix 3 — to the 
control flux fonnulated for use with eutectic PbSn solder hi 
each test, the standard configuration was used with the qua- 
ternary eutectic alloy. Tiie bath temperature was varied 
from 110 to 160°C. As expected, tlie control flux shows no 
wetting until the bath temperature is 160^'C. Fltix 3 performs 
similarly to the control flux and would not be a candidate 
for use with low-temperatme solders. Flux 1 is the most 
promising of the tliree developmental flux veliicles. Its wet- 
ting times at 1 lO^'C are equivalent to the wettmg times of 
flux 2 at 160°C. In addition, the eqtulibrium wetting force of 
0.5 niN is greater than tlie eqiiilibriimi wetting force of fiiiK 2. 



In simtmary, the ranking of fluxes in terms of activation re- 
quirements is (flux 1 < flux 2 < flux S and the control flux). 

Conclusions 

The wetting balance as a method to discriminate the wetting 
behaviors of vaiious solder aMoys and fluxes has been gen- 
erally successful. Replacing the standard etitectJc PbSn solder 
with a low^-temperatLuc solder alloy in the standard configu- 
ration was the most effective method for evaluating the low^- 
temperatm-e fliuxos. Operating in the standard configuration 
with a low-melting-pouit quateniar>' euiectic alloy, the wetting 
balance was able to rartk the fluxes in tenns of activation 
reqtiirement (flux 1 < flux 2 < flux 3 and the control fltix). 
The results iQustrate tlie usefulneSvS of wettuig force measure- 
ments in the characterization of low-temperattuie fluxes. 
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Berkeley. He joined HP in 
1 993 and initially worked on 
solder alloy and electrpnic 
assembly process develop- 
mont He is currently a reliabilsiy physics engineer at 
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resptinsibie for solder alloy selection and interconnect 
relisbiliiy. He was written over thirty technical papers 
on metallurgy and is named as an inventor m two 
pending patents. He is a member o1 the Minerals, 
Metals, and Materia Is Society. ASM, and the Ameri- 
can SGciet\' of Mechanical Engmeers. Zequn is 
marned. Priona joining HR he worked at Lawrence 
Berkeley Laboratory. 

Helen A. Holder 

A manufacturing develop- 
ment engineer at HP's Elec- 
tronics Assembly Develop- 
ment Canter, Helen Holder 
IS responsible for evaluating 
low-temperatyre fluxes and 
solder pastes and for devel- 
oping the manufacturing 
processes for high-volume 
production with Inw-temperatufe snlders. PreviOLisJy 
she was a process engineer at HP's Networked 
Computer Manufactunng Operation, working on HP 
7D0/XX Series tefminals and WindowsCliencs. She 
has auTtio^ed articles on Jov^-ten^perature solders, 
contract manufactunng, and thermally conductive 
arlhesives. She is a member of the Minerals, Mela Is. 
and Materials Society, ASM, the American Society of 
Mechanical Engineers, and the Surface Mount Tech- 
nology Association Helen earned a BS degree in 
mechanical engineering Uam the Massactiusetts 
Institute of Technology in 1993. Before iuining HR ahe 
worked at the Institute's ffuid mechanics laboratory 
designing and buildmg ultrasound ifansducers 
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HubertA. Vanrler Plas 

Hugh Vander P^as received 

»a BA degree in physics from 
Calvin CoHege in 1972. He 
went on to earn an MS de- 
gree in 1973 and a PhD in 
1 977, both m materials sci- 
ence and engineering from 
mg ; ''' Stanford University. Before 

K- ccr.ing to HP, he worked at 

Vanan As^uciaies on concentrator sofar cells and at 
Xerox Palo Alto Research Center on tfie metallization 
of Si wafers and amorphous silicon arrays. He joined 
HP's Electronic Assembly Development Center in 1989 
and vvorked on various surface mount technolDgJes. 
He also helped to remove Freon [CFCsi from HP's 
surface mount processes. Currently a member of the 
technical staff, he is working on flip-chip assembly, 
specifically sofdering Si die to pnnted circuit ooards, 
Previously he was responsible far evaluating low- 
temperature fluxes. He has v^ntten twenty-three pub- 
Hcahons in the areas of solar cell performance and 
fabrication and processes for advanced metal inter- 
connectivity. He is named as an inventor in a patent 
involving demountable tape automated bonding. He 
aEso has a patent pending on forming snider bumps 
on various substrates. Professionally interested in 
interconnect technologies, he is a member of the 
IEEE and American Scientific Arfiliation. Born in 
Downey. CaJifornia, Hugh is marhed ano has two 
chiJtfren. In his free time he trains soccer referees 
and is ooe himself. He is also active in a variety of 
youth sports and teaches high school Sunday school, 



Russell 6. Cinque 

Russell Cinque :s a senior process engineer at Intel 
Corporation's mask operation. Prevrously he worked 
on low- temperature fluK evaiuation with HP's Elec- 
tronic Assembly Development Center, conducting 
waning balance tests to characterize flux behavior. 
Russeli was born in Houston. Texas and earned a PhO 
degree in materials science from the University of 
California at Berkeley in 1995. 

Zequn Mei 

AutJior's biography appears elsewhere in this section. 

Helen Holder 

Author's biography appears elsewhere in this section. 



Hubert A. Vander Plas 

Author's biography appears elsewhere in this section. 
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